170 lines
6.0 KiB
Plaintext
170 lines
6.0 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_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 HAVE_INTEL_TXT
|
||
|
|
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 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 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
|
||
|
|
|