| # |
| # 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_PATH |
| bool "Security hooks for pathname based access control" |
| depends on SECURITY |
| help |
| This enables the security hooks for pathname based access control. |
| If enabled, a security module can use these hooks to |
| implement pathname based access controls. |
| 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 INTEL_TXT |
| bool "Enable Intel(R) Trusted Execution Technology (Intel(R) TXT)" |
| depends on EXPERIMENTAL && X86 && DMAR && ACPI |
| help |
| This option enables support for booting the kernel with the |
| Trusted Boot (tboot) module. This will utilize |
| Intel(R) Trusted Execution Technology to perform a measured launch |
| of the kernel. If the system does not support Intel(R) TXT, this |
| will have no effect. |
| |
| Intel TXT will provide higher assurance of sysem configuration and |
| initial state as well as data reset protection. This is used to |
| create a robust initial kernel measurement and verification, which |
| helps to ensure that kernel security mechanisms are functioning |
| correctly. This level of protection requires a root of trust outside |
| of the kernel itself. |
| |
| Intel TXT also helps solve real end user concerns about having |
| confidence that their hardware is running the VMM or kernel that |
| it was conigured with, especially since they may be responsible for |
| providing such assurances to VMs and services running on it. |
| |
| See <http://www.intel.com/technology/security/> for more information |
| about Intel(R) TXT. |
| See <http://tboot.sourceforge.net> for more information about tboot. |
| See Documentation/intel_txt.txt for a description of how to enable |
| Intel TXT support in a kernel boot. |
| |
| If you are unsure as to whether this is required, answer N. |
| |
| source security/selinux/Kconfig |
| source security/smack/Kconfig |
| source security/tomoyo/Kconfig |
| |
| source security/integrity/ima/Kconfig |
| |
| endmenu |
| |