#
# Security configuration
#

menu "Security options"

source grsecurity/Kconfig

menu "PaX"

config PAX
	bool "Enable various PaX features"
	depends on GRKERNSEC && (ALPHA || ARM || AVR32 || IA64 || MIPS32 || MIPS64 || PARISC || PPC32 || PPC64 || SPARC32 || SPARC64 || 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'
	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.

	  If you have applications not marked by the PT_PAX_FLAGS ELF
	  program header then you MUST enable this option otherwise they
	  will not get any protection.

	  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 you have applications not marked by the PT_PAX_FLAGS ELF
	  program header then you MUST enable the EI_PAX marking support
	  otherwise they will not get any protection.

	  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 || IA64 || MIPS32 || MIPS64 || PARISC || PPC32 || PPC64 || SPARC32 || SPARC64 || 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 !COMPAT_VDSO && PAX_NOEXEC && (!X86_32 || M586 || M586TSC || M586MMX || M686 || MPENTIUMII || MPENTIUMIII || MPENTIUMM || MCORE2 || MPENTIUM4 || MPSC || MK7 || MK8 || MWINCHIPC6 || MWINCHIP2 || MWINCHIP3D || MVIAC3_2 || MVIAC7)
	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 (e.g., ppc users
	  can make use of the secure-plt feature found in binutils).

config PAX_SEGMEXEC
	bool "Segmentation based non-executable pages"
	depends on !COMPAT_VDSO && 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 || PPC32 || X86)
	default y if PARISC || PPC32
	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 and ppc 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 || PPC32)
	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 and ppc 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) && !PPC64
	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.

	  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_NOELFRELOCS
	bool "Disallow ELF text relocations"
	depends on PAX_MPROTECT && !PAX_ETEXECRELOCS && (IA64 || X86)
	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,
	  then enable this option otherwise be careful as you may not even
	  be able to boot or log on your system (for example, some PAM
	  modules are erroneously compiled as non-PIC by default).

	  NOTE: if you are using dynamic ELF executables (as suggested
	  when using ASLR) then you must have made sure that you linked
	  your files using the PIC version of crt1 (the et_dyn.tar.gz package
	  referenced there has already been updated to support this).

config PAX_ETEXECRELOCS
	bool "Allow ELF ET_EXEC text relocations"
	depends on PAX_MPROTECT && (ALPHA || IA64 || PARISC)
	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 || PPC32 || SPARC32 || SPARC64)
	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,
	  ppc (if secure-plt is not used throughout in userland), 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
	depends on PAX_EMUPLT && (SPARC32 || SPARC64)
	default y

config PAX_SYSCALL
	bool
	depends on PAX_PAGEEXEC && PPC32
	default y

config PAX_KERNEXEC
	bool "Enforce non-executable kernel pages"
	depends on PAX_NOEXEC && X86 && !EFI && !COMPAT_VDSO && (!X86_32 || X86_WP_WORKS_OK) && !PARAVIRT
	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.

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 PAX_ASLR && X86_TSC && X86_32
	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_UDEREF
	bool "Prevent invalid userland pointer dereference"
	depends on X86_32 && !COMPAT_VDSO && !UML_X86
	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 X86
	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.
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 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.  It is not used by SELinux or SMACK.

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

config SECURITY_DEFAULT
	string "Default security module"
	depends on SECURITY
	default ""
	help
          This determines the security module used if the security=
          boot parmater is not provided.  If a security module is not
          specified the first module to register will be used.

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_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 SECURITY_DEFAULT_MMAP_MIN_ADDR
        int "Low address space to protect from user allocation"
        depends on SECURITY
        default 0
        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 would either need additional
	  permissions from either the LSM or the capabilities module or have
	  this protection disabled.

	  This value can be changed after boot using the
	  /proc/sys/vm/mmap_min_addr tunable.


source security/selinux/Kconfig
source security/smack/Kconfig
source security/apparmor/Kconfig

endmenu

