69575d3886
Move tboot.h from asm to linux to fix the build errors of intel_txt patch on non-X86 platforms. Remove the tboot code from generic code init/main.c and kernel/cpu.c. Signed-off-by: Shane Wang <shane.wang@intel.com> Signed-off-by: H. Peter Anvin <hpa@zytor.com>
154 lines
5.3 KiB
Plaintext
154 lines
5.3 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.
|
|
|
|
source security/selinux/Kconfig
|
|
source security/smack/Kconfig
|
|
source security/tomoyo/Kconfig
|
|
|
|
source security/integrity/ima/Kconfig
|
|
|
|
endmenu
|
|
|