#
# Security configuration
#

menu "Security options"

menu "PaX"

config PAX
	bool "Enable various PaX features"
	depends on GRKERNSEC && (ALPHA || ARM || IA64 || MIPS32 || MIPS64 || PARISC || PPC32 || PPC64 || SPARC32 || SPARC64 || X86 || X86_64)
	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_flags() itself,
	  - "hook": if your MAC system uses the pax_set_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 || X86_64)
	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 || MPENTIUM4 || MK7 || MK8 || MWINCHIPC6 || MWINCHIP2 || MWINCHIP3D || MVIAC3_2)
	select PAX_NOVSYSCALL if X86_32
	help
	  This implementation is based on the paging feature of the CPU.
	  On i386 and ppc there is a variable but usually low performance
	  impact on applications.  On alpha, ia64, parisc, sparc, sparc64
	  and x86_64 there is no performance impact.

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

choice
	prompt "Default non-executable page method"
	depends on PAX_PAGEEXEC && PAX_SEGMEXEC
	default PAX_DEFAULT_SEGMEXEC
	help
	  Select the default non-executable page method applied to applications
	  that do not select one themselves.

config	PAX_DEFAULT_PAGEEXEC
	bool "PAGEEXEC"

config	PAX_DEFAULT_SEGMEXEC
	bool "SEGMEXEC"
endchoice

config PAX_EMUTRAMP
	bool "Emulate trampolines" if (PAX_PAGEEXEC || PAX_SEGMEXEC) && (PARISC || PPC32 || X86_32)
	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 || X86_64)
	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,
	  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_32 && !HOTPLUG_PCI_COMPAQ_NVRAM && !PCI_BIOS && !EFI && !DEBUG_RODATA
	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.

config PAX_NOVSYSCALL
	bool "Disable the vsyscall page"
	depends on PAX_ASLR && X86_32
	help
	  The Linux 2.6 kernel introduced a new feature that speeds up or
	  simplifies certain operations, such as system calls or returns
	  from signal handlers.

	  Unfortunately the implementation also gives a powerful instrument
	  into the hands of exploit writers: the so-called vsyscall page exists
	  in every task at the same fixed address and it contains machine code
	  that is very useful in performing the return-to-libc style attack.

	  Since this exploit technique cannot in general be protected against
	  via kernel solutions, this option will allow you to disable the use
	  of the vsyscall page and revert back to the old behaviour.

endmenu

endmenu

source grsecurity/Kconfig

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 all keys may be viewed"
	depends on KEYS
	help
	  This option turns on support for the /proc/keys file through which
	  all the keys on the system can be listed.

	  This option is a slight security risk in that it makes it possible
	  for anyone to see all the keys on the system. Normally the manager
	  pretends keys that are inaccessible to a process don't exist as far
	  as that process is concerned.

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 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_CAPABILITIES
	tristate "Default Linux Capabilities"
	depends on SECURITY
	help
	  This enables the "default" Linux capabilities functionality.
	  If you are unsure how to answer this question, answer Y.

config SECURITY_ROOTPLUG
	tristate "Root Plug Support"
	depends on USB && 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_SECLVL
	tristate "BSD Secure Levels"
	depends on SECURITY
	select CRYPTO
	select CRYPTO_SHA1
	help
	  Implements BSD Secure Levels as an LSM.  See
	  <file:Documentation/seclvl.txt> for instructions on how to use this
	  module.

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

source security/selinux/Kconfig

endmenu

