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
 | |
| 
 |