renegade-project/linux-next
2
0
Fork 0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-26 22:24:09 +08:00
Code
492510dd7d
linux-next/security/integrity/evm/Kconfig

73 lines
2.2 KiB
Plaintext
Raw Normal View History

evm: re-release EVM protects a file's security extended attributes(xattrs) against integrity attacks. This patchset provides the framework and an initial method. The initial method maintains an HMAC-sha1 value across the security extended attributes, storing the HMAC value as the extended attribute 'security.evm'. Other methods of validating the integrity of a file's metadata will be posted separately (eg. EVM-digital-signatures). While this patchset does authenticate the security xattrs, and cryptographically binds them to the inode, coming extensions will bind other directory and inode metadata for more complete protection. To help simplify the review and upstreaming process, each extension will be posted separately (eg. IMA-appraisal, IMA-appraisal-directory). For a general overview of the proposed Linux integrity subsystem, refer to Dave Safford's whitepaper: http://downloads.sf.net/project/linux-ima/linux-ima/Integrity_overview.pdf. EVM depends on the Kernel Key Retention System to provide it with a trusted/encrypted key for the HMAC-sha1 operation. The key is loaded onto the root's keyring using keyctl. Until EVM receives notification that the key has been successfully loaded onto the keyring (echo 1 > <securityfs>/evm), EVM can not create or validate the 'security.evm' xattr, but returns INTEGRITY_UNKNOWN. Loading the key and signaling EVM should be done as early as possible. Normally this is done in the initramfs, which has already been measured as part of the trusted boot. For more information on creating and loading existing trusted/encrypted keys, refer to Documentation/keys-trusted-encrypted.txt. A sample dracut patch, which loads the trusted/encrypted key and enables EVM, is available from http://linux-ima.sourceforge.net/#EVM. Based on the LSMs enabled, the set of EVM protected security xattrs is defined at compile. EVM adds the following three calls to the existing security hooks: evm_inode_setxattr(), evm_inode_post_setxattr(), and evm_inode_removexattr. To initialize and update the 'security.evm' extended attribute, EVM defines three calls: evm_inode_post_init(), evm_inode_post_setattr() and evm_inode_post_removexattr() hooks. To verify the integrity of a security xattr, EVM exports evm_verifyxattr(). Changelog v7: - Fixed URL in EVM ABI documentation Changelog v6: (based on Serge Hallyn's review) - fix URL in patch description - remove evm_hmac_size definition - use SHA1_DIGEST_SIZE (removed both MAX_DIGEST_SIZE and evm_hmac_size) - moved linux include before other includes - test for crypto_hash_setkey failure - fail earlier for invalid key - clear entire encrypted key, even on failure - check xattr name length before comparing xattr names Changelog: - locking based on i_mutex, remove evm_mutex - using trusted/encrypted keys for storing the EVM key used in the HMAC-sha1 operation. - replaced crypto hash with shash (Dmitry Kasatkin) - support for additional methods of verifying the security xattrs (Dmitry Kasatkin) - iint not allocated for all regular files, but only for those appraised - Use cap_sys_admin in lieu of cap_mac_admin - Use __vfs_setxattr_noperm(), without permission checks, from EVM Signed-off-by: Mimi Zohar <zohar@us.ibm.com> Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
2011-03-16 04:12:09 +08:00
config EVM
kconfig: use bool instead of boolean for type definition attributes Support for keyword 'boolean' will be dropped later on. No functional change. Reference: http://lkml.kernel.org/r/cover.1418003065.git.cj@linux.com Signed-off-by: Christoph Jaeger <cj@linux.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
2014-12-21 04:41:11 +08:00
bool "EVM support"
evm: enable key retention service automatically If keys are not enabled, EVM is not visible in the configuration menu. It may be difficult to figure out what to do unless you really know. Other subsystems as NFS, CIFS select keys automatically. This patch does the same. This patch also removes '(TRUSTED_KEYS=y || TRUSTED_KEYS=n)' dependency, which is unnecessary. EVM does not depend on trusted keys, but on encrypted keys. evm.h provides compile time dependency. Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2014-02-28 20:18:09 +08:00
select KEYS
select ENCRYPTED_KEYS
evm: re-release EVM protects a file's security extended attributes(xattrs) against integrity attacks. This patchset provides the framework and an initial method. The initial method maintains an HMAC-sha1 value across the security extended attributes, storing the HMAC value as the extended attribute 'security.evm'. Other methods of validating the integrity of a file's metadata will be posted separately (eg. EVM-digital-signatures). While this patchset does authenticate the security xattrs, and cryptographically binds them to the inode, coming extensions will bind other directory and inode metadata for more complete protection. To help simplify the review and upstreaming process, each extension will be posted separately (eg. IMA-appraisal, IMA-appraisal-directory). For a general overview of the proposed Linux integrity subsystem, refer to Dave Safford's whitepaper: http://downloads.sf.net/project/linux-ima/linux-ima/Integrity_overview.pdf. EVM depends on the Kernel Key Retention System to provide it with a trusted/encrypted key for the HMAC-sha1 operation. The key is loaded onto the root's keyring using keyctl. Until EVM receives notification that the key has been successfully loaded onto the keyring (echo 1 > <securityfs>/evm), EVM can not create or validate the 'security.evm' xattr, but returns INTEGRITY_UNKNOWN. Loading the key and signaling EVM should be done as early as possible. Normally this is done in the initramfs, which has already been measured as part of the trusted boot. For more information on creating and loading existing trusted/encrypted keys, refer to Documentation/keys-trusted-encrypted.txt. A sample dracut patch, which loads the trusted/encrypted key and enables EVM, is available from http://linux-ima.sourceforge.net/#EVM. Based on the LSMs enabled, the set of EVM protected security xattrs is defined at compile. EVM adds the following three calls to the existing security hooks: evm_inode_setxattr(), evm_inode_post_setxattr(), and evm_inode_removexattr. To initialize and update the 'security.evm' extended attribute, EVM defines three calls: evm_inode_post_init(), evm_inode_post_setattr() and evm_inode_post_removexattr() hooks. To verify the integrity of a security xattr, EVM exports evm_verifyxattr(). Changelog v7: - Fixed URL in EVM ABI documentation Changelog v6: (based on Serge Hallyn's review) - fix URL in patch description - remove evm_hmac_size definition - use SHA1_DIGEST_SIZE (removed both MAX_DIGEST_SIZE and evm_hmac_size) - moved linux include before other includes - test for crypto_hash_setkey failure - fail earlier for invalid key - clear entire encrypted key, even on failure - check xattr name length before comparing xattr names Changelog: - locking based on i_mutex, remove evm_mutex - using trusted/encrypted keys for storing the EVM key used in the HMAC-sha1 operation. - replaced crypto hash with shash (Dmitry Kasatkin) - support for additional methods of verifying the security xattrs (Dmitry Kasatkin) - iint not allocated for all regular files, but only for those appraised - Use cap_sys_admin in lieu of cap_mac_admin - Use __vfs_setxattr_noperm(), without permission checks, from EVM Signed-off-by: Mimi Zohar <zohar@us.ibm.com> Acked-by: Serge Hallyn <serge.hallyn@canonical.com>
2011-03-16 04:12:09 +08:00
select CRYPTO_HMAC
select CRYPTO_SHA1
default n
help
EVM protects a file's security extended attributes against
integrity attacks.
If you are unsure how to answer this question, answer N.
evm: add file system uuid to EVM hmac EVM uses the same key for all file systems to calculate the HMAC, making it possible to paste inodes from one file system on to another one, without EVM being able to detect it. To prevent such an attack, it is necessary to make the EVM HMAC file system specific. This patch uses the file system UUID, a file system unique identifier, to bind the EVM HMAC to the file system. The value inode->i_sb->s_uuid is used for the HMAC hash calculation, instead of using it for deriving the file system specific key. Initializing the key for every inode HMAC calculation is a bit more expensive operation than adding the uuid to the HMAC hash. Changing the HMAC calculation method or adding additional info to the calculation, requires existing EVM labeled file systems to be relabeled. This patch adds a Kconfig HMAC version option for backwards compatability. Changelog v1: - squash "hmac version setting" Changelog v0: - add missing Kconfig depends (Mimi) Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2012-09-10 15:37:20 +08:00
evm: replace HMAC version with attribute mask Using HMAC version limits the posibility to arbitrarily add new attributes such as SMACK64EXEC to the hmac calculation. This patch replaces hmac version with attribute mask. Desired attributes can be enabled with configuration parameter. It allows to build kernels which works with previously labeled filesystems. Currently supported attribute is 'fsuuid' which is equivalent of the former version 2. Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2014-03-28 20:31:04 +08:00
config EVM_ATTR_FSUUID
bool "FSUUID (version 2)"
default y
evm: add file system uuid to EVM hmac EVM uses the same key for all file systems to calculate the HMAC, making it possible to paste inodes from one file system on to another one, without EVM being able to detect it. To prevent such an attack, it is necessary to make the EVM HMAC file system specific. This patch uses the file system UUID, a file system unique identifier, to bind the EVM HMAC to the file system. The value inode->i_sb->s_uuid is used for the HMAC hash calculation, instead of using it for deriving the file system specific key. Initializing the key for every inode HMAC calculation is a bit more expensive operation than adding the uuid to the HMAC hash. Changing the HMAC calculation method or adding additional info to the calculation, requires existing EVM labeled file systems to be relabeled. This patch adds a Kconfig HMAC version option for backwards compatability. Changelog v1: - squash "hmac version setting" Changelog v0: - add missing Kconfig depends (Mimi) Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2012-09-10 15:37:20 +08:00
depends on EVM
help
evm: replace HMAC version with attribute mask Using HMAC version limits the posibility to arbitrarily add new attributes such as SMACK64EXEC to the hmac calculation. This patch replaces hmac version with attribute mask. Desired attributes can be enabled with configuration parameter. It allows to build kernels which works with previously labeled filesystems. Currently supported attribute is 'fsuuid' which is equivalent of the former version 2. Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2014-03-28 20:31:04 +08:00
Include filesystem UUID for HMAC calculation.
Default value is 'selected', which is former version 2.
if 'not selected', it is former version 1
evm: add file system uuid to EVM hmac EVM uses the same key for all file systems to calculate the HMAC, making it possible to paste inodes from one file system on to another one, without EVM being able to detect it. To prevent such an attack, it is necessary to make the EVM HMAC file system specific. This patch uses the file system UUID, a file system unique identifier, to bind the EVM HMAC to the file system. The value inode->i_sb->s_uuid is used for the HMAC hash calculation, instead of using it for deriving the file system specific key. Initializing the key for every inode HMAC calculation is a bit more expensive operation than adding the uuid to the HMAC hash. Changing the HMAC calculation method or adding additional info to the calculation, requires existing EVM labeled file systems to be relabeled. This patch adds a Kconfig HMAC version option for backwards compatability. Changelog v1: - squash "hmac version setting" Changelog v0: - add missing Kconfig depends (Mimi) Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2012-09-10 15:37:20 +08:00
evm: replace HMAC version with attribute mask Using HMAC version limits the posibility to arbitrarily add new attributes such as SMACK64EXEC to the hmac calculation. This patch replaces hmac version with attribute mask. Desired attributes can be enabled with configuration parameter. It allows to build kernels which works with previously labeled filesystems. Currently supported attribute is 'fsuuid' which is equivalent of the former version 2. Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2014-03-28 20:31:04 +08:00
WARNING: changing the HMAC calculation method or adding
evm: add file system uuid to EVM hmac EVM uses the same key for all file systems to calculate the HMAC, making it possible to paste inodes from one file system on to another one, without EVM being able to detect it. To prevent such an attack, it is necessary to make the EVM HMAC file system specific. This patch uses the file system UUID, a file system unique identifier, to bind the EVM HMAC to the file system. The value inode->i_sb->s_uuid is used for the HMAC hash calculation, instead of using it for deriving the file system specific key. Initializing the key for every inode HMAC calculation is a bit more expensive operation than adding the uuid to the HMAC hash. Changing the HMAC calculation method or adding additional info to the calculation, requires existing EVM labeled file systems to be relabeled. This patch adds a Kconfig HMAC version option for backwards compatability. Changelog v1: - squash "hmac version setting" Changelog v0: - add missing Kconfig depends (Mimi) Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@intel.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2012-09-10 15:37:20 +08:00
additional info to the calculation, requires existing EVM
evm: replace HMAC version with attribute mask Using HMAC version limits the posibility to arbitrarily add new attributes such as SMACK64EXEC to the hmac calculation. This patch replaces hmac version with attribute mask. Desired attributes can be enabled with configuration parameter. It allows to build kernels which works with previously labeled filesystems. Currently supported attribute is 'fsuuid' which is equivalent of the former version 2. Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2014-03-28 20:31:04 +08:00
labeled file systems to be relabeled.
evm: provide option to protect additional SMACK xattrs Newer versions of SMACK introduced following security xattrs: SMACK64EXEC, SMACK64TRANSMUTE and SMACK64MMAP. To protect these xattrs, this patch includes them in the HMAC calculation. However, for backwards compatibility with existing labeled filesystems, including these xattrs needs to be configurable. Changelog: - Add SMACK dependency on new option (Mimi) Signed-off-by: Dmitry Kasatkin <d.kasatkin@samsung.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2014-03-28 20:31:14 +08:00
config EVM_EXTRA_SMACK_XATTRS
bool "Additional SMACK xattrs"
depends on EVM && SECURITY_SMACK
default n
help
Include additional SMACK xattrs for HMAC calculation.
In addition to the original security xattrs (eg. security.selinux,
security.SMACK64, security.capability, and security.ima) included
in the HMAC calculation, enabling this option includes newly defined
Smack xattrs: security.SMACK64EXEC, security.SMACK64TRANSMUTE and
security.SMACK64MMAP.
WARNING: changing the HMAC calculation method or adding
additional info to the calculation, requires existing EVM
labeled file systems to be relabeled.
EVM: Allow runtime modification of the set of verified xattrs Sites may wish to provide additional metadata alongside files in order to make more fine-grained security decisions[1]. The security of this is enhanced if this metadata is protected, something that EVM makes possible. However, the kernel cannot know about the set of extended attributes that local admins may wish to protect, and hardcoding this policy in the kernel makes it difficult to change over time and less convenient for distributions to enable. This patch adds a new /sys/kernel/security/integrity/evm/evm_xattrs node, which can be read to obtain the current set of EVM-protected extended attributes or written to in order to add new entries. Extending this list will not change the validity of any existing signatures provided that the file in question does not have any of the additional extended attributes - missing xattrs are skipped when calculating the EVM hash. [1] For instance, a package manager could install information about the package uploader in an additional extended attribute. Local LSM policy could then be associated with that extended attribute in order to restrict the privileges available to packages from less trusted uploaders. Signed-off-by: Matthew Garrett <mjg59@google.com> Reviewed-by: James Morris <james.morris@microsoft.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2018-05-16 01:38:26 +08:00
config EVM_ADD_XATTRS
bool "Add additional EVM extended attributes at runtime"
depends on EVM
default n
help
Allow userland to provide additional xattrs for HMAC calculation.
When this option is enabled, root can add additional xattrs to the
list used by EVM by writing them into
/sys/kernel/security/integrity/evm/evm_xattrs.
evm: load an x509 certificate from the kernel This patch defines a configuration option and the evm_load_x509() hook to load an X509 certificate onto the EVM trusted kernel keyring. Changes in v4: * Patch description updated Changes in v3: * Removed EVM_X509_PATH definition. CONFIG_EVM_X509_PATH is used directly. Changes in v2: * default key patch changed to /etc/keys Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@huawei.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2015-10-23 02:26:21 +08:00
config EVM_LOAD_X509
bool "Load an X509 certificate onto the '.evm' trusted keyring"
evm: EVM_LOAD_X509 depends on EVM The newly added EVM_LOAD_X509 code can be configured even if CONFIG_EVM is disabled, but that causes a link error: security/built-in.o: In function `integrity_load_keys': digsig_asymmetric.c:(.init.text+0x400): undefined reference to `evm_load_x509' This adds a Kconfig dependency to ensure it is only enabled when CONFIG_EVM is set as well. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Fixes: 2ce523eb8976 ("evm: load x509 certificate from the kernel") Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2015-11-27 21:52:33 +08:00
depends on EVM && INTEGRITY_TRUSTED_KEYRING
evm: load an x509 certificate from the kernel This patch defines a configuration option and the evm_load_x509() hook to load an X509 certificate onto the EVM trusted kernel keyring. Changes in v4: * Patch description updated Changes in v3: * Removed EVM_X509_PATH definition. CONFIG_EVM_X509_PATH is used directly. Changes in v2: * default key patch changed to /etc/keys Signed-off-by: Dmitry Kasatkin <dmitry.kasatkin@huawei.com> Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com>
2015-10-23 02:26:21 +08:00
default n
help
Load an X509 certificate onto the '.evm' trusted keyring.
This option enables X509 certificate loading from the kernel
onto the '.evm' trusted keyring. A public key can be used to
verify EVM integrity starting from the 'init' process.
config EVM_X509_PATH
string "EVM X509 certificate path"
depends on EVM_LOAD_X509
default "/etc/keys/x509_evm.der"
help
This option defines X509 certificate path.
Copy Permalink