#
# Security configuration
#
menu "Security options"
menu "Grsecurity"
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_USERCOPY_SLABS
bool
config GRKERNSEC
bool "Grsecurity"
select CRYPTO
select CRYPTO_SHA256
select PROC_FS
select STOP_MACHINE
select DEBUG_KERNEL
select DEBUG_LIST
help
If you say Y here, you will be able to configure many features
that will enhance the security of your system. It is highly
recommended that you say Y here and read through the help
for each option so that you fully understand the features and
can evaluate their usefulness for your machine.
choice
prompt "Configuration Method"
depends on GRKERNSEC
default GRKERNSEC_CONFIG_CUSTOM
help
config GRKERNSEC_CONFIG_AUTO
bool "Automatic"
help
If you choose this configuration method, you'll be able to answer a small
number of simple questions about how you plan to use this kernel.
The settings of grsecurity and PaX will be automatically configured for
the highest commonly-used settings within the provided constraints.
If you require additional configuration, custom changes can still be made
from the "custom configuration" menu.
config GRKERNSEC_CONFIG_CUSTOM
bool "Custom"
help
If you choose this configuration method, you'll be able to configure all
grsecurity and PaX settings manually. Via this method, no options are
automatically enabled.
endchoice
choice
prompt "Usage Type"
depends on (GRKERNSEC && GRKERNSEC_CONFIG_AUTO)
default GRKERNSEC_CONFIG_SERVER
help
config GRKERNSEC_CONFIG_SERVER
bool "Server"
help
Choose this option if you plan to use this kernel on a server.
config GRKERNSEC_CONFIG_DESKTOP
bool "Desktop"
help
Choose this option if you plan to use this kernel on a desktop.
endchoice
choice
prompt "Virtualization Type"
depends on (GRKERNSEC && X86 && GRKERNSEC_CONFIG_AUTO)
default GRKERNSEC_CONFIG_VIRT_NONE
help
config GRKERNSEC_CONFIG_VIRT_NONE
bool "None"
help
Choose this option if this kernel will be run on bare metal.
config GRKERNSEC_CONFIG_VIRT_GUEST
bool "Guest"
help
Choose this option if this kernel will be run as a VM guest.
config GRKERNSEC_CONFIG_VIRT_HOST
bool "Host"
help
Choose this option if this kernel will be run as a VM host.
endchoice
choice
prompt "Virtualization Hardware"
depends on (GRKERNSEC && X86 && GRKERNSEC_CONFIG_AUTO && (GRKERNSEC_CONFIG_VIRT_GUEST || GRKERNSEC_CONFIG_VIRT_HOST))
help
config GRKERNSEC_CONFIG_VIRT_EPT
bool "EPT/RVI Processor Support"
depends on X86
help
Choose this option if your CPU supports the EPT or RVI features of 2nd-gen
hardware virtualization. This allows for additional kernel hardening protections
to operate without additional performance impact.
To see if your Intel processor supports EPT, see:
http://ark.intel.com/Products/VirtualizationTechnology
(Most Core i3/5/7 support EPT)
To see if your AMD processor supports RVI, see:
http://support.amd.com/us/kbarticles/Pages/GPU120AMDRVICPUsHyperVWin8.aspx
config GRKERNSEC_CONFIG_VIRT_SOFT
bool "First-gen/No Hardware Virtualization"
help
Choose this option if you use an Atom/Pentium/Core 2 processor that either doesn't
support hardware virtualization or doesn't support the EPT/RVI extensions.
endchoice
choice
prompt "Virtualization Software"
depends on (GRKERNSEC && GRKERNSEC_CONFIG_AUTO && (GRKERNSEC_CONFIG_VIRT_GUEST || GRKERNSEC_CONFIG_VIRT_HOST))
help
config GRKERNSEC_CONFIG_VIRT_XEN
bool "Xen"
help
Choose this option if this kernel is running as a Xen guest or host.
config GRKERNSEC_CONFIG_VIRT_VMWARE
bool "VMWare"
help
Choose this option if this kernel is running as a VMWare guest or host.
config GRKERNSEC_CONFIG_VIRT_KVM
bool "KVM"
help
Choose this option if this kernel is running as a KVM guest or host.
config GRKERNSEC_CONFIG_VIRT_VIRTUALBOX
bool "VirtualBox"
help
Choose this option if this kernel is running as a VirtualBox guest or host.
endchoice
choice
prompt "Required Priorities"
depends on (GRKERNSEC && GRKERNSEC_CONFIG_AUTO)
default GRKERNSEC_CONFIG_PRIORITY_PERF
help
config GRKERNSEC_CONFIG_PRIORITY_PERF
bool "Performance"
help
Choose this option if performance is of highest priority for this deployment
of grsecurity. Features like UDEREF on a 64bit kernel, kernel stack clearing,
clearing of structures intended for userland, and freed memory sanitizing will
be disabled.
config GRKERNSEC_CONFIG_PRIORITY_SECURITY
bool "Security"
help
Choose this option if security is of highest priority for this deployment of
grsecurity. UDEREF, kernel stack clearing, clearing of structures intended
for userland, and freed memory sanitizing will be enabled for this kernel.
In a worst-case scenario, these features can introduce a 20% performance hit
(UDEREF on x64 contributing half of this hit).
endchoice
menu "Default Special Groups"
depends on (GRKERNSEC && GRKERNSEC_CONFIG_AUTO)
config GRKERNSEC_PROC_GID
int "GID exempted from /proc restrictions"
default 1001
help
Setting this GID determines which group will be exempted from
grsecurity's /proc restrictions, allowing users of the specified
group to view network statistics and the existence of other users'
processes on the system. This GID may also be chosen at boot time
via "grsec_proc_gid=" on the kernel commandline.
config GRKERNSEC_TPE_UNTRUSTED_GID
int "GID for TPE-untrusted users"
depends on GRKERNSEC_CONFIG_SERVER && GRKERNSEC_TPE && !GRKERNSEC_TPE_INVERT
default 1005
help
Setting this GID determines which group untrusted users should
be added to. These users will be placed under grsecurity's Trusted Path
Execution mechanism, preventing them from executing their own binaries.
The users will only be able to execute binaries in directories owned and
writable only by the root user. If the sysctl option is enabled, a sysctl
option with name "tpe_gid" is created.
config GRKERNSEC_TPE_TRUSTED_GID
int "GID for TPE-trusted users"
depends on GRKERNSEC_CONFIG_SERVER && GRKERNSEC_TPE && GRKERNSEC_TPE_INVERT
default 1005
help
Setting this GID determines what group TPE restrictions will be
*disabled* for. If the sysctl option is enabled, a sysctl option
with name "tpe_gid" is created.
config GRKERNSEC_SYMLINKOWN_GID
int "GID for users with kernel-enforced SymlinksIfOwnerMatch"
depends on GRKERNSEC_CONFIG_SERVER
default 1006
help
Setting this GID determines what group kernel-enforced
SymlinksIfOwnerMatch will be enabled for. If the sysctl option
is enabled, a sysctl option with name "symlinkown_gid" is created.
endmenu
menu "Customize Configuration"
depends on GRKERNSEC
menu "PaX"
config PAX
bool "Enable various PaX features"
default y if GRKERNSEC_CONFIG_AUTO
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'
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 or XATTR_PAX_FLAGS
support as they are 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'
default y if GRKERNSEC_CONFIG_AUTO
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 and XATTR_PAX_FLAGS
support.
Note that if you enable PT_PAX_FLAGS or XATTR_PAX_FLAGS marking
support as well, they will override the legacy EI_PAX marks.
If you enable none of the marking options then all applications
will run with PaX enabled on them by default.
config PAX_PT_PAX_FLAGS
bool 'Use ELF program header marking'
default y if GRKERNSEC_CONFIG_AUTO
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).
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.
If you enable both PT_PAX_FLAGS and XATTR_PAX_FLAGS support then you
must make sure that the marks are the same if a binary has both marks.
If you enable none of the marking options then all applications
will run with PaX enabled on them by default.
config PAX_XATTR_PAX_FLAGS
bool 'Use filesystem extended attributes marking'
default y if GRKERNSEC_CONFIG_AUTO
select CIFS_XATTR if CIFS
select EXT2_FS_XATTR if EXT2_FS
select EXT3_FS_XATTR if EXT3_FS
select JFFS2_FS_XATTR if JFFS2_FS
select REISERFS_FS_XATTR if REISERFS_FS
select SQUASHFS_XATTR if SQUASHFS
select TMPFS_XATTR if TMPFS
select UBIFS_FS_XATTR if UBIFS_FS
help
Enabling this option will allow you to control PaX features on
a per executable basis via the 'setfattr' utility. The control
flags will be read from the user.pax.flags extended attribute of
the file. This marking has the benefit of supporting binary-only
applications that self-check themselves (e.g., skype) and would
not tolerate chpax/paxctl changes. The main drawback is that
extended attributes are not supported by some filesystems (e.g.,
isofs, udf, vfat) so copying files through such filesystems will
lose the extended attributes and these PaX markings.
Note that if you enable the legacy EI_PAX marking support as well,
the EI_PAX marks will be overridden by the XATTR_PAX_FLAGS marks.
If you enable both PT_PAX_FLAGS and XATTR_PAX_FLAGS support then you
must make sure that the marks are the same if a binary has both marks.
If you enable none of the marking options then all applications
will run with PaX enabled on them by default.
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"
default y if GRKERNSEC_CONFIG_AUTO
depends on 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"
default y if GRKERNSEC_CONFIG_AUTO
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 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"
default y if GRKERNSEC_CONFIG_AUTO
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"
default y if PARISC || GRKERNSEC_CONFIG_AUTO
depends on (PAX_PAGEEXEC || PAX_SEGMEXEC) && (PARISC || X86)
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()"
default y if GRKERNSEC_CONFIG_AUTO
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)"
default y if (GRKERNSEC_CONFIG_AUTO && GRKERNSEC_CONFIG_DESKTOP)
depends on PAX_MPROTECT
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"
default y if GRKERNSEC_CONFIG_AUTO && (GRKERNSEC_CONFIG_VIRT_NONE || (GRKERNSEC_CONFIG_VIRT_EPT && GRKERNSEC_CONFIG_VIRT_GUEST) || (GRKERNSEC_CONFIG_VIRT_EPT && GRKERNSEC_CONFIG_VIRT_KVM))
depends on X86 && !XEN && (!X86_32 || X86_WP_WORKS_OK)
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.
choice
prompt "Return Address Instrumentation Method"
default PAX_KERNEXEC_PLUGIN_METHOD_BTS
depends on PAX_KERNEXEC_PLUGIN
help
Select the method used to instrument function pointer dereferences.
Note that binary modules cannot be instrumented by this approach.
Note that the implementation requires a gcc with plugin support,
i.e., gcc 4.5 or newer. You may need to install the supporting
headers explicitly in addition to the normal gcc package.
config PAX_KERNEXEC_PLUGIN_METHOD_BTS
bool "bts"
help
This method is compatible with binary only modules but has
a higher runtime overhead.
config PAX_KERNEXEC_PLUGIN_METHOD_OR
bool "or"
depends on !PARAVIRT
help
This method is incompatible with binary only modules but has
a lower runtime overhead.
endchoice
config PAX_KERNEXEC_PLUGIN_METHOD
string
default "bts" if PAX_KERNEXEC_PLUGIN_METHOD_BTS
default "or" if PAX_KERNEXEC_PLUGIN_METHOD_OR
default ""
config PAX_KERNEXEC_MODULE_TEXT
int "Minimum amount of memory reserved for module code"
default "4" if (!GRKERNSEC_CONFIG_AUTO || GRKERNSEC_CONFIG_SERVER)
default "12" if (GRKERNSEC_CONFIG_AUTO && GRKERNSEC_CONFIG_DESKTOP)
depends on PAX_KERNEXEC && X86_32
help
Due to implementation details the kernel must reserve a fixed
amount of memory for runtime allocated code (such as modules)
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 runtime allocated 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"
default y if GRKERNSEC_CONFIG_AUTO
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"
default y if GRKERNSEC_CONFIG_AUTO && !(GRKERNSEC_CONFIG_VIRT_HOST && GRKERNSEC_CONFIG_VIRT_VIRTUALBOX)
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"
default y if GRKERNSEC_CONFIG_AUTO
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"
default y if GRKERNSEC_CONFIG_AUTO
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"
default y if (GRKERNSEC_CONFIG_AUTO && GRKERNSEC_CONFIG_PRIORITY_SECURITY)
help
By saying Y here the kernel will erase memory pages and slab objects
as soon as they are freed. This in turn reduces the lifetime of data
stored in them, 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 ensure timely freeing of memory that may hold sensitive
information.
A nice side effect of the sanitization of slab objects is the
reduction of possible info leaks caused by padding bytes within the
leaky structures. Use-after-free bugs for structures containing
pointers can also be detected as dereferencing the sanitized pointer
will generate an access violation.
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.
To reduce the performance penalty by sanitizing pages only, albeit
limiting the effectiveness of this feature at the same time, slab
sanitization can be disabled with the kernel commandline parameter
"pax_sanitize_slab=0".
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"
default y if (GRKERNSEC_CONFIG_AUTO && GRKERNSEC_CONFIG_PRIORITY_SECURITY)
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 that the full feature requires a gcc with plugin support,
i.e., gcc 4.5 or newer. You may need to install the supporting
headers explicitly in addition to the normal gcc package. 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_STRUCTLEAK
bool "Forcibly initialize local variables copied to userland"
default y if (GRKERNSEC_CONFIG_AUTO && GRKERNSEC_CONFIG_PRIORITY_SECURITY)
help
By saying Y here the kernel will zero initialize some local
variables that are going to be copied to userland. This in
turn prevents unintended information leakage from the kernel
stack should later code forget to explicitly set all parts of
the copied variable.
The tradeoff is less performance impact than PAX_MEMORY_STACKLEAK
at a much smaller coverage.
Note that the implementation requires a gcc with plugin support,
i.e., gcc 4.5 or newer. You may need to install the supporting
headers explicitly in addition to the normal gcc package.
config PAX_MEMORY_UDEREF
bool "Prevent invalid userland pointer dereference"
default y if GRKERNSEC_CONFIG_AUTO && (X86_32 || (X86_64 && GRKERNSEC_CONFIG_PRIORITY_SECURITY)) && (GRKERNSEC_CONFIG_VIRT_NONE || GRKERNSEC_CONFIG_VIRT_EPT)
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"
default y if GRKERNSEC_CONFIG_AUTO
depends on GRKERNSEC && ((ARM && (CPU_32v6 || CPU_32v6K || CPU_32v7)) || SPARC64 || 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.
config PAX_USERCOPY
bool "Harden heap object copies between kernel and userland"
default y if GRKERNSEC_CONFIG_AUTO
depends on ARM || IA64 || PPC || SPARC || X86
depends on GRKERNSEC && (SLAB || SLUB || SLOB)
select PAX_USERCOPY_SLABS
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.
config PAX_USERCOPY_DEBUG
bool
depends on X86 && PAX_USERCOPY
default n
config PAX_CONSTIFY_PLUGIN
bool "Automatically constify eligible structures"
default y if GRKERNSEC_CONFIG_AUTO
depends on !UML && PAX_KERNEXEC
help
By saying Y here the compiler will automatically constify a class
of types that contain only function pointers. This reduces the
kernel's attack surface and also produces a better memory layout.
Note that the implementation requires a gcc with plugin support,
i.e., gcc 4.5 or newer. You may need to install the supporting
headers explicitly in addition to the normal gcc package
Note that if some code really has to modify constified variables
then the source code will have to be patched to allow it. Examples
can be found in PaX itself (the no_const attribute) and for some
out-of-tree modules at http://www.grsecurity.net/~paxguy1/ .
config PAX_SIZE_OVERFLOW
bool "Prevent various integer overflows in function size parameters"
default y if GRKERNSEC_CONFIG_AUTO
depends on X86
help
By saying Y here the kernel recomputes expressions of function
arguments marked by a size_overflow attribute with double integer
precision (DImode/TImode for 32/64 bit integer types).
The recomputed argument is checked against TYPE_MAX and an event
is logged on overflow and the triggering process is killed.
Homepage: http://www.grsecurity.net/~ephox/overflow_plugin/
Note that the implementation requires a gcc with plugin support,
i.e., gcc 4.5 or newer. You may need to install the supporting
headers explicitly in addition to the normal gcc package.
config PAX_LATENT_ENTROPY
bool "Generate some entropy during boot and runtime"
default y if GRKERNSEC_CONFIG_AUTO
help
By saying Y here the kernel will instrument some kernel code to
extract some entropy from both original and artificially created
program state. This will help especially embedded systems where
there is little 'natural' source of entropy normally. The cost
is some slowdown of the boot process and fork and irq processing.
When pax_extra_latent_entropy is passed on the kernel command line,
entropy will be extracted from up to the first 4GB of RAM while the
runtime memory allocator is being initialized. This costs even more
slowdown of the boot process.
Note that the implementation requires a gcc with plugin support,
i.e., gcc 4.5 or newer. You may need to install the supporting
headers explicitly in addition to the normal gcc package.
Note that entropy extracted this way is not cryptographically
secure!
endmenu
endmenu
source grsecurity/Kconfig
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
select CRYPTO
select CRYPTO_HMAC
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 for more information
about Intel(R) TXT.
See 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/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