mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-30 16:13:54 +08:00
3323eec921
IMA provides hardware (TPM) based measurement and attestation for file measurements. As the Trusted Computing (TPM) model requires, IMA measures all files before they are accessed in any way (on the integrity_bprm_check, integrity_path_check and integrity_file_mmap hooks), and commits the measurements to the TPM. Once added to the TPM, measurements can not be removed. In addition, IMA maintains a list of these file measurements, which can be used to validate the aggregate value stored in the TPM. The TPM can sign these measurements, and thus the system can prove, to itself and to a third party, the system's integrity in a way that cannot be circumvented by malicious or compromised software. - alloc ima_template_entry before calling ima_store_template() - log ima_add_boot_aggregate() failure - removed unused IMA_TEMPLATE_NAME_LEN - replaced hard coded string length with #define name Signed-off-by: Mimi Zohar <zohar@us.ibm.com> Signed-off-by: James Morris <jmorris@namei.org>
134 lines
4.4 KiB
Plaintext
134 lines
4.4 KiB
Plaintext
#
|
|
# Security configuration
|
|
#
|
|
|
|
menu "Security options"
|
|
|
|
config KEYS
|
|
bool "Enable access key retention support"
|
|
help
|
|
This option provides support for retaining authentication tokens and
|
|
access keys in the kernel.
|
|
|
|
It also includes provision of methods by which such keys might be
|
|
associated with a process so that network filesystems, encryption
|
|
support and the like can find them.
|
|
|
|
Furthermore, a special type of key is available that acts as keyring:
|
|
a searchable sequence of keys. Each process is equipped with access
|
|
to five standard keyrings: UID-specific, GID-specific, session,
|
|
process and thread.
|
|
|
|
If you are unsure as to whether this is required, answer N.
|
|
|
|
config KEYS_DEBUG_PROC_KEYS
|
|
bool "Enable the /proc/keys file by which keys may be viewed"
|
|
depends on KEYS
|
|
help
|
|
This option turns on support for the /proc/keys file - through which
|
|
can be listed all the keys on the system that are viewable by the
|
|
reading process.
|
|
|
|
The only keys included in the list are those that grant View
|
|
permission to the reading process whether or not it possesses them.
|
|
Note that LSM security checks are still performed, and may further
|
|
filter out keys that the current process is not authorised to view.
|
|
|
|
Only key attributes are listed here; key payloads are not included in
|
|
the resulting table.
|
|
|
|
If you are unsure as to whether this is required, answer N.
|
|
|
|
config SECURITY
|
|
bool "Enable different security models"
|
|
depends on SYSFS
|
|
help
|
|
This allows you to choose different security modules to be
|
|
configured into your kernel.
|
|
|
|
If this option is not selected, the default Linux security
|
|
model will be used.
|
|
|
|
If you are unsure how to answer this question, answer N.
|
|
|
|
config SECURITYFS
|
|
bool "Enable the securityfs filesystem"
|
|
help
|
|
This will build the securityfs filesystem. It is currently used by
|
|
the TPM bios character driver and IMA, an integrity provider. It is
|
|
not used by SELinux or SMACK.
|
|
|
|
If you are unsure how to answer this question, answer N.
|
|
|
|
config SECURITY_NETWORK
|
|
bool "Socket and Networking Security Hooks"
|
|
depends on SECURITY
|
|
help
|
|
This enables the socket and networking security hooks.
|
|
If enabled, a security module can use these hooks to
|
|
implement socket and networking access controls.
|
|
If you are unsure how to answer this question, answer N.
|
|
|
|
config SECURITY_NETWORK_XFRM
|
|
bool "XFRM (IPSec) Networking Security Hooks"
|
|
depends on XFRM && SECURITY_NETWORK
|
|
help
|
|
This enables the XFRM (IPSec) networking security hooks.
|
|
If enabled, a security module can use these hooks to
|
|
implement per-packet access controls based on labels
|
|
derived from IPSec policy. Non-IPSec communications are
|
|
designated as unlabelled, and only sockets authorized
|
|
to communicate unlabelled data can send without using
|
|
IPSec.
|
|
If you are unsure how to answer this question, answer N.
|
|
|
|
config SECURITY_FILE_CAPABILITIES
|
|
bool "File POSIX Capabilities"
|
|
default n
|
|
help
|
|
This enables filesystem capabilities, allowing you to give
|
|
binaries a subset of root's powers without using setuid 0.
|
|
|
|
If in doubt, answer N.
|
|
|
|
config SECURITY_ROOTPLUG
|
|
bool "Root Plug Support"
|
|
depends on USB=y && SECURITY
|
|
help
|
|
This is a sample LSM module that should only be used as such.
|
|
It prevents any programs running with egid == 0 if a specific
|
|
USB device is not present in the system.
|
|
|
|
See <http://www.linuxjournal.com/article.php?sid=6279> for
|
|
more information about this module.
|
|
|
|
If you are unsure how to answer this question, answer N.
|
|
|
|
config SECURITY_DEFAULT_MMAP_MIN_ADDR
|
|
int "Low address space to protect from user allocation"
|
|
depends on SECURITY
|
|
default 0
|
|
help
|
|
This is the portion of low virtual memory which should be protected
|
|
from userspace allocation. Keeping a user from writing to low pages
|
|
can help reduce the impact of kernel NULL pointer bugs.
|
|
|
|
For most ia64, ppc64 and x86 users with lots of address space
|
|
a value of 65536 is reasonable and should cause no problems.
|
|
On arm and other archs it should not be higher than 32768.
|
|
Programs which use vm86 functionality would either need additional
|
|
permissions from either the LSM or the capabilities module or have
|
|
this protection disabled.
|
|
|
|
This value can be changed after boot using the
|
|
/proc/sys/vm/mmap_min_addr tunable.
|
|
|
|
|
|
source security/selinux/Kconfig
|
|
source security/smack/Kconfig
|
|
|
|
source security/integrity/ima/Kconfig
|
|
|
|
endmenu
|
|
|