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 all keys may be viewed"
+ 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
- all the keys on the system can be listed.
+ 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.
- This option is a slight security risk in that it makes it possible
- for anyone to see all the keys on the system. Normally the manager
- pretends keys that are inaccessible to a process don't exist as far
- as that process is concerned.
+ 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"
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
IPSec.
If you are unsure how to answer this question, answer N.
-config SECURITY_CAPABILITIES
- tristate "Default Linux Capabilities"
+config SECURITY_PATH
+ bool "Security hooks for pathname based access control"
depends on SECURITY
help
- This enables the "default" Linux capabilities functionality.
- If you are unsure how to answer this question, answer Y.
+ 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
- tristate "Root Plug Support"
- depends on USB && SECURITY
+ 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
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_SECLVL
- tristate "BSD Secure Levels"
- depends on SECURITY
- select CRYPTO
- select CRYPTO_SHA1
+config INTEL_TXT
+ bool "Enable Intel(R) Trusted Execution Technology (Intel(R) TXT)"
+ depends on HAVE_INTEL_TXT
help
- Implements BSD Secure Levels as an LSM. See
- <file:Documentation/seclvl.txt> for instructions on how to use this
- module.
+ 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 system 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 configured 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 how to answer this question, answer N.
+ If you are unsure as to whether this is required, answer N.
+
+config LSM_MMAP_MIN_ADDR
+ int "Low address space for LSM to protect from user allocation"
+ depends on SECURITY && SECURITY_SELINUX
+ default 65536
+ 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 or have some need to map
+ this low address space will need the permission specific to the
+ systems running LSM.
source security/selinux/Kconfig
+source security/smack/Kconfig
+source security/tomoyo/Kconfig
+
+source security/integrity/ima/Kconfig
endmenu