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.

This option provides support for creating, sealing, and unsealing
keys in the kernel. Trusted keys are random number symmetric keys,
generated and RSA-sealed by the TPM. The TPM only unseals the keys,
if the boot PCRs and other criteria match.  Userspace will only ever
see encrypted blobs.

If you are unsure as to whether this is required, answer N.

This option provides support for create/encrypting/decrypting keys
in the kernel.  Encrypted keys are kernel generated random numbers,
which are encrypted/decrypted with a 'master' symmetric key. The
'master' key can be either a trusted-key or user-key type.
Userspace only ever sees/stores encrypted blobs.

If you are unsure as to whether this is required, answer N.

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.

This enforces restrictions on unprivileged users reading the kernel
syslog via dmesg(8).

If this option is not selected, no restrictions will be enforced
unless the dmesg_restrict sysctl is explicitly set to (1).

If you are unsure how to answer this question, answer N.

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.

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.

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.

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.

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.

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.

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.

Select the security module that will be used by default if the
kernel parameter security= is not specified.

config DEFAULT_SECURITY_SELINUX
bool "SELinux" if SECURITY_SELINUX=y

config DEFAULT_SECURITY_SMACK
bool "Simplified Mandatory Access Control" if SECURITY_SMACK=y

config DEFAULT_SECURITY_TOMOYO
bool "TOMOYO" if SECURITY_TOMOYO=y

config DEFAULT_SECURITY_APPARMOR
bool "AppArmor" if SECURITY_APPARMOR=y

config DEFAULT_SECURITY_DAC
bool "Unix Discretionary Access Controls"