#
# Security configuration
#

menu "Security options"

source grsecurity/Kconfig

menu "PaX"

	config ARCH_TRACK_EXEC_LIMIT
	bool

	config PAX_KERNEXEC_PLUGIN
	bool

	config PAX_PER_CPU_PGD
	bool

	config TASK_SIZE_MAX_SHIFT
	int
	depends on X86_64
	default 47 if !PAX_PER_CPU_PGD
	default 42 if PAX_PER_CPU_PGD

	config PAX_ENABLE_PAE
	bool
	default y if (X86_32 && (MPENTIUM4 || MK8 || MPSC || MCORE2 || MATOM))
	
config PAX
	bool "Enable various PaX features"
	depends on GRKERNSEC && (ALPHA || ARM || AVR32 || IA64 || MIPS || PARISC || PPC || SPARC || X86)
	help
	  This allows you to enable various PaX features.  PaX adds
	  intrusion prevention mechanisms to the kernel that reduce
	  the risks posed by exploitable memory corruption bugs.

menu "PaX Control"
	depends on PAX

config PAX_SOFTMODE
	bool 'Support soft mode'
	select PAX_PT_PAX_FLAGS
	help
	  Enabling this option will allow you to run PaX in soft mode, that
	  is, PaX features will not be enforced by default, only on executables
	  marked explicitly.  You must also enable PT_PAX_FLAGS support as it
	  is the only way to mark executables for soft mode use.

	  Soft mode can be activated by using the "pax_softmode=1" kernel command
	  line option on boot.  Furthermore you can control various PaX features
	  at runtime via the entries in /proc/sys/kernel/pax.

config PAX_EI_PAX
	bool 'Use legacy ELF header marking'
	help
	  Enabling this option will allow you to control PaX features on
	  a per executable basis via the 'chpax' utility available at
	  http://pax.grsecurity.net/.  The control flags will be read from
	  an otherwise reserved part of the ELF header.  This marking has
	  numerous drawbacks (no support for soft-mode, toolchain does not
	  know about the non-standard use of the ELF header) therefore it
	  has been deprecated in favour of PT_PAX_FLAGS support.

	  Note that if you enable PT_PAX_FLAGS marking support as well,
	  the PT_PAX_FLAG marks will override the legacy EI_PAX marks.

config PAX_PT_PAX_FLAGS
	bool 'Use ELF program header marking'
	help
	  Enabling this option will allow you to control PaX features on
	  a per executable basis via the 'paxctl' utility available at
	  http://pax.grsecurity.net/.  The control flags will be read from
	  a PaX specific ELF program header (PT_PAX_FLAGS).  This marking
	  has the benefits of supporting both soft mode and being fully
	  integrated into the toolchain (the binutils patch is available
	  from http://pax.grsecurity.net).

	  If your toolchain does not support PT_PAX_FLAGS markings,
	  you can create one in most cases with 'paxctl -C'.

	  Note that if you enable the legacy EI_PAX marking support as well,
	  the EI_PAX marks will be overridden by the PT_PAX_FLAGS marks.

choice
	prompt 'MAC system integration'
	default PAX_HAVE_ACL_FLAGS
	help
	  Mandatory Access Control systems have the option of controlling
	  PaX flags on a per executable basis, choose the method supported
	  by your particular system.

	  - "none": if your MAC system does not interact with PaX,
	  - "direct": if your MAC system defines pax_set_initial_flags() itself,
	  - "hook": if your MAC system uses the pax_set_initial_flags_func callback.

	  NOTE: this option is for developers/integrators only.

	config PAX_NO_ACL_FLAGS
		bool 'none'

	config PAX_HAVE_ACL_FLAGS
		bool 'direct'

	config PAX_HOOK_ACL_FLAGS
		bool 'hook'
endchoice

endmenu

menu "Non-executable pages"
	depends on PAX

config PAX_NOEXEC
	bool "Enforce non-executable pages"
	depends on (PAX_EI_PAX || PAX_PT_PAX_FLAGS || PAX_HAVE_ACL_FLAGS || PAX_HOOK_ACL_FLAGS) && (ALPHA || (ARM && (CPU_V6 || CPU_V7)) || IA64 || MIPS || PARISC || PPC || S390 || SPARC || X86)
	help
	  By design some architectures do not allow for protecting memory
	  pages against execution or even if they do, Linux does not make
	  use of this feature.  In practice this means that if a page is
	  readable (such as the stack or heap) it is also executable.

	  There is a well known exploit technique that makes use of this
	  fact and a common programming mistake where an attacker can
	  introduce code of his choice somewhere in the attacked program's
	  memory (typically the stack or the heap) and then execute it.

	  If the attacked program was running with different (typically
	  higher) privileges than that of the attacker, then he can elevate
	  his own privilege level (e.g. get a root shell, write to files for
	  which he does not have write access to, etc).

	  Enabling this option will let you choose from various features
	  that prevent the injection and execution of 'foreign' code in
	  a program.

	  This will also break programs that rely on the old behaviour and
	  expect that dynamically allocated memory via the malloc() family
	  of functions is executable (which it is not).  Notable examples
	  are the XFree86 4.x server, the java runtime and wine.

config PAX_PAGEEXEC
	bool "Paging based non-executable pages"
	depends on PAX_NOEXEC && (!X86_32 || M586 || M586TSC || M586MMX || M686 || MPENTIUMII || MPENTIUMIII || MPENTIUMM || MCORE2 || MATOM || MPENTIUM4 || MPSC || MK7 || MK8 || MWINCHIPC6 || MWINCHIP2 || MWINCHIP3D || MVIAC3_2 || MVIAC7)
	select S390_SWITCH_AMODE if S390
	select S390_EXEC_PROTECT if S390
	select ARCH_TRACK_EXEC_LIMIT if X86_32
	help
	  This implementation is based on the paging feature of the CPU.
	  On i386 without hardware non-executable bit support there is a
	  variable but usually low performance impact, however on Intel's
	  P4 core based CPUs it is very high so you should not enable this
	  for kernels meant to be used on such CPUs.

	  On alpha, avr32, ia64, parisc, sparc, sparc64, x86_64 and i386
	  with hardware non-executable bit support there is no performance
	  impact, on ppc the impact is negligible.

	  Note that several architectures require various emulations due to
	  badly designed userland ABIs, this will cause a performance impact
	  but will disappear as soon as userland is fixed. For example, ppc
	  userland MUST have been built with secure-plt by a recent toolchain.

config PAX_SEGMEXEC
	bool "Segmentation based non-executable pages"
	depends on PAX_NOEXEC && X86_32
	help
	  This implementation is based on the segmentation feature of the
	  CPU and has a very small performance impact, however applications
	  will be limited to a 1.5 GB address space instead of the normal
	  3 GB.

config PAX_EMUTRAMP
	bool "Emulate trampolines" if (PAX_PAGEEXEC || PAX_SEGMEXEC) && (PARISC || X86)
	default y if PARISC
	help
	  There are some programs and libraries that for one reason or
	  another attempt to execute special small code snippets from
	  non-executable memory pages.  Most notable examples are the
	  signal handler return code generated by the kernel itself and
	  the GCC trampolines.

	  If you enabled CONFIG_PAX_PAGEEXEC or CONFIG_PAX_SEGMEXEC then
	  such programs will no longer work under your kernel.

	  As a remedy you can say Y here and use the 'chpax' or 'paxctl'
	  utilities to enable trampoline emulation for the affected programs
	  yet still have the protection provided by the non-executable pages.

	  On parisc you MUST enable this option and EMUSIGRT as well, otherwise
	  your system will not even boot.

	  Alternatively you can say N here and use the 'chpax' or 'paxctl'
	  utilities to disable CONFIG_PAX_PAGEEXEC and CONFIG_PAX_SEGMEXEC
	  for the affected files.

	  NOTE: enabling this feature *may* open up a loophole in the
	  protection provided by non-executable pages that an attacker
	  could abuse.  Therefore the best solution is to not have any
	  files on your system that would require this option.  This can
	  be achieved by not using libc5 (which relies on the kernel
	  signal handler return code) and not using or rewriting programs
	  that make use of the nested function implementation of GCC.
	  Skilled users can just fix GCC itself so that it implements
	  nested function calls in a way that does not interfere with PaX.

config PAX_EMUSIGRT
	bool "Automatically emulate sigreturn trampolines"
	depends on PAX_EMUTRAMP && PARISC
	default y
	help
	  Enabling this option will have the kernel automatically detect
	  and emulate signal return trampolines executing on the stack
	  that would otherwise lead to task termination.

	  This solution is intended as a temporary one for users with
	  legacy versions of libc (libc5, glibc 2.0, uClibc before 0.9.17,
	  Modula-3 runtime, etc) or executables linked to such, basically
	  everything that does not specify its own SA_RESTORER function in
	  normal executable memory like glibc 2.1+ does.

	  On parisc you MUST enable this option, otherwise your system will
	  not even boot.

	  NOTE: this feature cannot be disabled on a per executable basis
	  and since it *does* open up a loophole in the protection provided
	  by non-executable pages, the best solution is to not have any
	  files on your system that would require this option.

config PAX_MPROTECT
	bool "Restrict mprotect()"
	depends on (PAX_PAGEEXEC || PAX_SEGMEXEC)
	help
	  Enabling this option will prevent programs from
	   - changing the executable status of memory pages that were
	     not originally created as executable,
	   - making read-only executable pages writable again,
	   - creating executable pages from anonymous memory,
	   - making read-only-after-relocations (RELRO) data pages writable again.

	  You should say Y here to complete the protection provided by
	  the enforcement of non-executable pages.

	  NOTE: you can use the 'chpax' or 'paxctl' utilities to control
	  this feature on a per file basis.

config PAX_MPROTECT_COMPAT
	bool "Use legacy/compat protection demoting (read help)"
	depends on PAX_MPROTECT
	default n
	help
	  The current implementation of PAX_MPROTECT denies RWX allocations/mprotects
	  by sending the proper error code to the application.  For some broken 
	  userland, this can cause problems with Python or other applications.  The
	  current implementation however allows for applications like clamav to
	  detect if JIT compilation/execution is allowed and to fall back gracefully
	  to an interpreter-based mode if it does not.  While we encourage everyone
	  to use the current implementation as-is and push upstream to fix broken
	  userland (note that the RWX logging option can assist with this), in some
	  environments this may not be possible.  Having to disable MPROTECT
	  completely on certain binaries reduces the security benefit of PaX,
	  so this option is provided for those environments to revert to the old
	  behavior.
	  
config PAX_ELFRELOCS
	bool "Allow ELF text relocations (read help)"
	depends on PAX_MPROTECT
	default n
	help
	  Non-executable pages and mprotect() restrictions are effective
	  in preventing the introduction of new executable code into an
	  attacked task's address space.  There remain only two venues
	  for this kind of attack: if the attacker can execute already
	  existing code in the attacked task then he can either have it
	  create and mmap() a file containing his code or have it mmap()
	  an already existing ELF library that does not have position
	  independent code in it and use mprotect() on it to make it
	  writable and copy his code there.  While protecting against
	  the former approach is beyond PaX, the latter can be prevented
	  by having only PIC ELF libraries on one's system (which do not
	  need to relocate their code).  If you are sure this is your case,
	  as is the case with all modern Linux distributions, then leave
	  this option disabled.  You should say 'n' here.

config PAX_ETEXECRELOCS
	bool "Allow ELF ET_EXEC text relocations"
	depends on PAX_MPROTECT && (ALPHA || IA64 || PARISC)
	select PAX_ELFRELOCS
	default y
	help
	  On some architectures there are incorrectly created applications
	  that require text relocations and would not work without enabling
	  this option.  If you are an alpha, ia64 or parisc user, you should
	  enable this option and disable it once you have made sure that
	  none of your applications need it.

config PAX_EMUPLT
	bool "Automatically emulate ELF PLT"
	depends on PAX_MPROTECT && (ALPHA || PARISC || SPARC)
	default y
	help
	  Enabling this option will have the kernel automatically detect
	  and emulate the Procedure Linkage Table entries in ELF files.
	  On some architectures such entries are in writable memory, and
	  become non-executable leading to task termination.  Therefore
	  it is mandatory that you enable this option on alpha, parisc,
	  sparc and sparc64, otherwise your system would not even boot.

	  NOTE: this feature *does* open up a loophole in the protection
	  provided by the non-executable pages, therefore the proper
	  solution is to modify the toolchain to produce a PLT that does
	  not need to be writable.

config PAX_DLRESOLVE
	bool 'Emulate old glibc resolver stub'
	depends on PAX_EMUPLT && SPARC
	default n
	help
	  This option is needed if userland has an old glibc (before 2.4)
	  that puts a 'save' instruction into the runtime generated resolver
	  stub that needs special emulation.

config PAX_KERNEXEC
	bool "Enforce non-executable kernel pages"
	depends on (PPC || X86) && (!X86_32 || X86_WP_WORKS_OK) && !XEN
	select PAX_PER_CPU_PGD if X86_64 || (X86_32 && X86_PAE)
	select PAX_KERNEXEC_PLUGIN if X86_64
	help
	  This is the kernel land equivalent of PAGEEXEC and MPROTECT,
	  that is, enabling this option will make it harder to inject
	  and execute 'foreign' code in kernel memory itself.

	  Note that on x86_64 kernels there is a known regression when
	  this feature and KVM/VMX are both enabled in the host kernel.

config PAX_KERNEXEC_MODULE_TEXT
	int "Minimum amount of memory reserved for module code"
	default "4"
	depends on PAX_KERNEXEC && X86_32 && MODULES
	help
	  Due to implementation details the kernel must reserve a fixed
	  amount of memory for module code at compile time that cannot be
	  changed at runtime.  Here you can specify the minimum amount
	  in MB that will be reserved.  Due to the same implementation
	  details this size will always be rounded up to the next 2/4 MB
	  boundary (depends on PAE) so the actually available memory for
	  module code will usually be more than this minimum.

	  The default 4 MB should be enough for most users but if you have
	  an excessive number of modules (e.g., most distribution configs
	  compile many drivers as modules) or use huge modules such as
	  nvidia's kernel driver, you will need to adjust this amount.
	  A good rule of thumb is to look at your currently loaded kernel
	  modules and add up their sizes.

endmenu

menu "Address Space Layout Randomization"
	depends on PAX

config PAX_ASLR
	bool "Address Space Layout Randomization"
	depends on PAX_EI_PAX || PAX_PT_PAX_FLAGS || PAX_HAVE_ACL_FLAGS || PAX_HOOK_ACL_FLAGS
	help
	  Many if not most exploit techniques rely on the knowledge of
	  certain addresses in the attacked program.  The following options
	  will allow the kernel to apply a certain amount of randomization
	  to specific parts of the program thereby forcing an attacker to
	  guess them in most cases.  Any failed guess will most likely crash
	  the attacked program which allows the kernel to detect such attempts
	  and react on them.  PaX itself provides no reaction mechanisms,
	  instead it is strongly encouraged that you make use of Nergal's
	  segvguard (ftp://ftp.pl.openwall.com/misc/segvguard/) or grsecurity's
	  (http://www.grsecurity.net/) built-in crash detection features or
	  develop one yourself.

	  By saying Y here you can choose to randomize the following areas:
	   - top of the task's kernel stack
	   - top of the task's userland stack
	   - base address for mmap() requests that do not specify one
	     (this includes all libraries)
	   - base address of the main executable

	  It is strongly recommended to say Y here as address space layout
	  randomization has negligible impact on performance yet it provides
	  a very effective protection.

	  NOTE: you can use the 'chpax' or 'paxctl' utilities to control
	  this feature on a per file basis.

config PAX_RANDKSTACK
	bool "Randomize kernel stack base"
	depends on X86_TSC && X86
	help
	  By saying Y here the kernel will randomize every task's kernel
	  stack on every system call.  This will not only force an attacker
	  to guess it but also prevent him from making use of possible
	  leaked information about it.

	  Since the kernel stack is a rather scarce resource, randomization
	  may cause unexpected stack overflows, therefore you should very
	  carefully test your system.  Note that once enabled in the kernel
	  configuration, this feature cannot be disabled on a per file basis.

config PAX_RANDUSTACK
	bool "Randomize user stack base"
	depends on PAX_ASLR
	help
	  By saying Y here the kernel will randomize every task's userland
	  stack.  The randomization is done in two steps where the second
	  one may apply a big amount of shift to the top of the stack and
	  cause problems for programs that want to use lots of memory (more
	  than 2.5 GB if SEGMEXEC is not active, or 1.25 GB when it is).
	  For this reason the second step can be controlled by 'chpax' or
	  'paxctl' on a per file basis.

config PAX_RANDMMAP
	bool "Randomize mmap() base"
	depends on PAX_ASLR
	help
	  By saying Y here the kernel will use a randomized base address for
	  mmap() requests that do not specify one themselves.  As a result
	  all dynamically loaded libraries will appear at random addresses
	  and therefore be harder to exploit by a technique where an attacker
	  attempts to execute library code for his purposes (e.g. spawn a
	  shell from an exploited program that is running at an elevated
	  privilege level).

	  Furthermore, if a program is relinked as a dynamic ELF file, its
	  base address will be randomized as well, completing the full
	  randomization of the address space layout.  Attacking such programs
	  becomes a guess game.  You can find an example of doing this at
	  http://pax.grsecurity.net/et_dyn.tar.gz and practical samples at
	  http://www.grsecurity.net/grsec-gcc-specs.tar.gz .

	  NOTE: you can use the 'chpax' or 'paxctl' utilities to control this
	  feature on a per file basis.

endmenu

menu "Miscellaneous hardening features"

config PAX_MEMORY_SANITIZE
	bool "Sanitize all freed memory"
	help
	  By saying Y here the kernel will erase memory pages as soon as they
	  are freed.  This in turn reduces the lifetime of data stored in the
	  pages, making it less likely that sensitive information such as
	  passwords, cryptographic secrets, etc stay in memory for too long.

	  This is especially useful for programs whose runtime is short, long
	  lived processes and the kernel itself benefit from this as long as
	  they operate on whole memory pages and ensure timely freeing of pages
	  that may hold sensitive information.

	  The tradeoff is performance impact, on a single CPU system kernel
	  compilation sees a 3% slowdown, other systems and workloads may vary
	  and you are advised to test this feature on your expected workload
	  before deploying it.

	  Note that this feature does not protect data stored in live pages,
	  e.g., process memory swapped to disk may stay there for a long time.

config PAX_MEMORY_STACKLEAK
	bool "Sanitize kernel stack"
	depends on X86
	help
	  By saying Y here the kernel will erase the kernel stack before it
	  returns from a system call.  This in turn reduces the information
	  that a kernel stack leak bug can reveal.

	  Note that such a bug can still leak information that was put on
	  the stack by the current system call (the one eventually triggering
	  the bug) but traces of earlier system calls on the kernel stack
	  cannot leak anymore.

	  The tradeoff is performance impact: on a single CPU system kernel
	  compilation sees a 1% slowdown, other systems and workloads may vary
	  and you are advised to test this feature on your expected workload
	  before deploying it.

	  Note: full support for this feature requires gcc with plugin support
	  so make sure your compiler is at least gcc 4.5.0 (cross compilation
	  is not supported).  Using older gcc versions means that functions
	  with large enough stack frames may leave uninitialized memory behind
	  that may be exposed to a later syscall leaking the stack.

config PAX_MEMORY_UDEREF
	bool "Prevent invalid userland pointer dereference"
	depends on X86 && !UML_X86 && !XEN
	select PAX_PER_CPU_PGD if X86_64
	help
	  By saying Y here the kernel will be prevented from dereferencing
	  userland pointers in contexts where the kernel expects only kernel
	  pointers.  This is both a useful runtime debugging feature and a
	  security measure that prevents exploiting a class of kernel bugs.

	  The tradeoff is that some virtualization solutions may experience
	  a huge slowdown and therefore you should not enable this feature
	  for kernels meant to run in such environments.  Whether a given VM
	  solution is affected or not is best determined by simply trying it
	  out, the performance impact will be obvious right on boot as this
	  mechanism engages from very early on.  A good rule of thumb is that
	  VMs running on CPUs without hardware virtualization support (i.e.,
	  the majority of IA-32 CPUs) will likely experience the slowdown.

config PAX_REFCOUNT
	bool "Prevent various kernel object reference counter overflows"
	depends on GRKERNSEC && (X86 || SPARC64)
	help
	  By saying Y here the kernel will detect and prevent overflowing
	  various (but not all) kinds of object reference counters.  Such
	  overflows can normally occur due to bugs only and are often, if
	  not always, exploitable.

	  The tradeoff is that data structures protected by an overflowed
	  refcount will never be freed and therefore will leak memory.  Note
	  that this leak also happens even without this protection but in
	  that case the overflow can eventually trigger the freeing of the
	  data structure while it is still being used elsewhere, resulting
	  in the exploitable situation that this feature prevents.

	  Since this has a negligible performance impact, you should enable
	  this feature.

config PAX_USERCOPY
	bool "Harden heap object copies between kernel and userland"
	depends on X86 || PPC || SPARC || ARM
	depends on GRKERNSEC && (SLAB || SLUB || SLOB)
	help
	  By saying Y here the kernel will enforce the size of heap objects
	  when they are copied in either direction between the kernel and
	  userland, even if only a part of the heap object is copied.

	  Specifically, this checking prevents information leaking from the
	  kernel heap during kernel to userland copies (if the kernel heap
	  object is otherwise fully initialized) and prevents kernel heap
	  overflows during userland to kernel copies.

	  Note that the current implementation provides the strictest bounds
	  checks for the SLUB allocator.

	  Enabling this option also enables per-slab cache protection against
	  data in a given cache being copied into/out of via userland
	  accessors.  Though the whitelist of regions will be reduced over
	  time, it notably protects important data structures like task structs.

	  If frame pointers are enabled on x86, this option will also restrict
	  copies into and out of the kernel stack to local variables within a
	  single frame.

	  Since this has a negligible performance impact, you should enable
	  this feature.

endmenu

endmenu

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 TRUSTED_KEYS
	tristate "TRUSTED KEYS"
	depends on KEYS && TCG_TPM
	select CRYPTO
	select CRYPTO_HMAC
	select CRYPTO_SHA1
	help
	  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.

config ENCRYPTED_KEYS
	tristate "ENCRYPTED KEYS"
	depends on KEYS && TRUSTED_KEYS
	select CRYPTO_AES
	select CRYPTO_CBC
	select CRYPTO_SHA256
	select CRYPTO_RNG
	help
	  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.

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_DMESG_RESTRICT
	bool "Restrict unprivileged access to the kernel syslog"
	default n
	help
	  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.

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 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 32768 if ALPHA || ARM || PARISC || SPARC32
	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/apparmor/Kconfig

source security/integrity/ima/Kconfig

choice
	prompt "Default security module"
	default DEFAULT_SECURITY_SELINUX if SECURITY_SELINUX
	default DEFAULT_SECURITY_SMACK if SECURITY_SMACK
	default DEFAULT_SECURITY_TOMOYO if SECURITY_TOMOYO
	default DEFAULT_SECURITY_APPARMOR if SECURITY_APPARMOR
	default DEFAULT_SECURITY_DAC

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

endchoice

config DEFAULT_SECURITY
	string
	default "selinux" if DEFAULT_SECURITY_SELINUX
	default "smack" if DEFAULT_SECURITY_SMACK
	default "tomoyo" if DEFAULT_SECURITY_TOMOYO
	default "apparmor" if DEFAULT_SECURITY_APPARMOR
	default "" if DEFAULT_SECURITY_DAC

endmenu

