Commit f4f27d00 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security 

Pull security subsystem updates from James Morris:
 "Highlights:

   - A new LSM, "LoadPin", from Kees Cook is added, which allows forcing
     of modules and firmware to be loaded from a specific device (this
     is from ChromeOS, where the device as a whole is verified
     cryptographically via dm-verity).

     This is disabled by default but can be configured to be enabled by
     default (don't do this if you don't know what you're doing).

   - Keys: allow authentication data to be stored in an asymmetric key.
     Lots of general fixes and updates.

   - SELinux: add restrictions for loading of kernel modules via
     finit_module().  Distinguish non-init user namespace capability
     checks.  Apply execstack check on thread stacks"

* 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (48 commits)
  LSM: LoadPin: provide enablement CONFIG
  Yama: use atomic allocations when reporting
  seccomp: Fix comment typo
  ima: add support for creating files using the mknodat syscall
  ima: fix ima_inode_post_setattr
  vfs: forbid write access when reading a file into memory
  fs: fix over-zealous use of "const"
  selinux: apply execstack check on thread stacks
  selinux: distinguish non-init user namespace capability checks
  LSM: LoadPin for kernel file loading restrictions
  fs: define a string representation of the kernel_read_file_id enumeration
  Yama: consolidate error reporting
  string_helpers: add kstrdup_quotable_file
  string_helpers: add kstrdup_quotable_cmdline
  string_helpers: add kstrdup_quotable
  selinux: check ss_initialized before revalidating an inode label
  selinux: delay inode label lookup as long as possible
  selinux: don't revalidate an inode's label when explicitly setting it
  selinux: Change bool variable name to index.
  KEYS: Add KEYCTL_DH_COMPUTE command
  ...
parents 2600a46e b937190c

Documentation/security/LoadPin.txt

0 → 100644
+17 −0
Original line number Original line Diff line number Diff line 
LoadPin is a Linux Security Module that ensures all kernel-loaded files

(modules, firmware, etc) all originate from the same filesystem, with

the expectation that such a filesystem is backed by a read-only device

such as dm-verity or CDROM. This allows systems that have a verified

and/or unchangeable filesystem to enforce module and firmware loading

restrictions without needing to sign the files individually.



The LSM is selectable at build-time with CONFIG_SECURITY_LOADPIN, and

can be controlled at boot-time with the kernel command line option

"loadpin.enabled". By default, it is enabled, but can be disabled at

boot ("loadpin.enabled=0").



LoadPin starts pinning when it sees the first file loaded. If the

block device backing the filesystem is not read-only, a sysctl is

created to toggle pinning: /proc/sys/kernel/loadpin/enabled. (Having

a mutable filesystem means pinning is mutable too, but having the

sysctl allows for easy testing on systems with a mutable filesystem.)

Documentation/security/keys.txt

+52 −0
Original line number Original line Diff line number Diff line
@@ -823,6 +823,36 @@ The keyctl syscall functions are: 
     A process must have search permission on the key for this function to be

     A process must have search permission on the key for this function to be

     successful.

     successful.





 (*) Compute a Diffie-Hellman shared secret or public key



       long keyctl(KEYCTL_DH_COMPUTE, struct keyctl_dh_params *params,

		   char *buffer, size_t buflen);



     The params struct contains serial numbers for three keys:



	 - The prime, p, known to both parties

	 - The local private key

	 - The base integer, which is either a shared generator or the

	   remote public key



     The value computed is:



	result = base ^ private (mod prime)



     If the base is the shared generator, the result is the local

     public key.  If the base is the remote public key, the result is

     the shared secret.



     The buffer length must be at least the length of the prime, or zero.



     If the buffer length is nonzero, the length of the result is

     returned when it is successfully calculated and copied in to the

     buffer. When the buffer length is zero, the minimum required

     buffer length is returned.



     This function will return error EOPNOTSUPP if the key type is not

     supported, error ENOKEY if the key could not be found, or error

     EACCES if the key is not readable by the caller.





===============

===============

KERNEL SERVICES

KERNEL SERVICES
@@ -999,6 +1029,10 @@ payload contents" for more information. 
	struct key *keyring_alloc(const char *description, uid_t uid, gid_t gid,

	struct key *keyring_alloc(const char *description, uid_t uid, gid_t gid,

				  const struct cred *cred,

				  const struct cred *cred,

				  key_perm_t perm,

				  key_perm_t perm,

				  int (*restrict_link)(struct key *,

						       const struct key_type *,

						       unsigned long,

						       const union key_payload *),

				  unsigned long flags,

				  unsigned long flags,

				  struct key *dest);

				  struct key *dest);
@@ -1010,6 +1044,24 @@ payload contents" for more information. 
    KEY_ALLOC_NOT_IN_QUOTA in flags if the keyring shouldn't be accounted

    KEY_ALLOC_NOT_IN_QUOTA in flags if the keyring shouldn't be accounted

    towards the user's quota).  Error ENOMEM can also be returned.

    towards the user's quota).  Error ENOMEM can also be returned.





    If restrict_link not NULL, it should point to a function that will be

    called each time an attempt is made to link a key into the new keyring.

    This function is called to check whether a key may be added into the keying

    or not.  Callers of key_create_or_update() within the kernel can pass

    KEY_ALLOC_BYPASS_RESTRICTION to suppress the check.  An example of using

    this is to manage rings of cryptographic keys that are set up when the

    kernel boots where userspace is also permitted to add keys - provided they

    can be verified by a key the kernel already has.



    When called, the restriction function will be passed the keyring being

    added to, the key flags value and the type and payload of the key being

    added.  Note that when a new key is being created, this is called between

    payload preparsing and actual key creation.  The function should return 0

    to allow the link or an error to reject it.



    A convenience function, restrict_link_reject, exists to always return

    -EPERM to in this case.







(*) To check the validity of a key, this function can be called:

(*) To check the validity of a key, this function can be called:

MAINTAINERS

+6 −0
Original line number Original line Diff line number Diff line
@@ -10025,6 +10025,12 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/jj/apparmor-dev.git 
S:	Supported

S:	Supported

F:	security/apparmor/

F:	security/apparmor/





LOADPIN SECURITY MODULE

M:	Kees Cook <keescook@chromium.org>

T:	git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git lsm/loadpin

S:	Supported

F:	security/loadpin/



YAMA SECURITY MODULE

YAMA SECURITY MODULE

M:	Kees Cook <keescook@chromium.org>

M:	Kees Cook <keescook@chromium.org>

T:	git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git yama/tip

T:	git git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git yama/tip

arch/x86/kernel/kexec-bzimage64.c

+4 −14
Original line number Original line Diff line number Diff line
@@ -19,8 +19,7 @@ 
#include <linux/kernel.h>

#include <linux/kernel.h>

#include <linux/mm.h>

#include <linux/mm.h>

#include <linux/efi.h>

#include <linux/efi.h>

#include <linux/verify_pefile.h>

#include <linux/verification.h>

#include <keys/system_keyring.h>





#include <asm/bootparam.h>

#include <asm/bootparam.h>

#include <asm/setup.h>

#include <asm/setup.h>
@@ -529,18 +528,9 @@ static int bzImage64_cleanup(void *loader_data) 
#ifdef CONFIG_KEXEC_BZIMAGE_VERIFY_SIG

#ifdef CONFIG_KEXEC_BZIMAGE_VERIFY_SIG

static int bzImage64_verify_sig(const char *kernel, unsigned long kernel_len)

static int bzImage64_verify_sig(const char *kernel, unsigned long kernel_len)

{

{

	bool trusted;

	return verify_pefile_signature(kernel, kernel_len,

	int ret;

				       NULL,



				       VERIFYING_KEXEC_PE_SIGNATURE);

	ret = verify_pefile_signature(kernel, kernel_len,

				      system_trusted_keyring,

				      VERIFYING_KEXEC_PE_SIGNATURE,

				      &trusted);

	if (ret < 0)

		return ret;

	if (!trusted)

		return -EKEYREJECTED;

	return 0;

}

}

#endif

#endif

certs/Kconfig

+9 −0
Original line number Original line Diff line number Diff line
@@ -17,6 +17,7 @@ config MODULE_SIG_KEY 
config SYSTEM_TRUSTED_KEYRING

config SYSTEM_TRUSTED_KEYRING

	bool "Provide system-wide ring of trusted keys"

	bool "Provide system-wide ring of trusted keys"

	depends on KEYS

	depends on KEYS

	depends on ASYMMETRIC_KEY_TYPE

	help

	help

	  Provide a system keyring to which trusted keys can be added.  Keys in

	  Provide a system keyring to which trusted keys can be added.  Keys in

	  the keyring are considered to be trusted.  Keys may be added at will

	  the keyring are considered to be trusted.  Keys may be added at will
@@ -55,4 +56,12 @@ config SYSTEM_EXTRA_CERTIFICATE_SIZE 
	  This is the number of bytes reserved in the kernel image for a

	  This is the number of bytes reserved in the kernel image for a

	  certificate to be inserted.

	  certificate to be inserted.





config SECONDARY_TRUSTED_KEYRING

	bool "Provide a keyring to which extra trustable keys may be added"

	depends on SYSTEM_TRUSTED_KEYRING

	help

	  If set, provide a keyring to which extra keys may be added, provided

	  those keys are not blacklisted and are vouched for by a key built

	  into the kernel or already in the secondary trusted keyring.



endmenu
 
endmenu

CRA Git | Maintained and supported by SUSTech CRA and CCSE