HardenedBSD

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.

Configuration Method

Choose between automatic or custom configuration here.

Automatic

GRKERNSEC_CONFIG_AUTO\

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.

Custom

GRKERNSEC_CONFIG_CUSTOM\

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.

Take note that if menuconfig is exited with this configuration method
chosen, you will not be able to use the automatic configuration methods
without starting again with a kernel configuration with no grsecurity
or PaX options specified inside.

Usage Type

Choose between server or desktop here.

Server

GRKERNSEC_CONFIG_SERVER\

Choose this option if you plan to use this kernel on a server.

Desktop

GRKERNSEC_CONFIG_DESKTOP\

Choose this option if you plan to use this kernel on a desktop.

Virtualization Type

Choose between no, guest, or host virtualization here.

None

GRKERNSEC_CONFIG_VIRT_NONE\

Choose this option if this kernel will be run on bare metal.

Guest

GRKERNSEC_CONFIG_VIRT_GUEST\

Choose this option if this kernel will be run as a VM guest.

Host

GRKERNSEC_CONFIG_VIRT_HOST\

Choose this option if this kernel will be run as a VM host.

Virtualization Hardware

Choose between no or EPT/RVI hardware virtualization support here.

EPT/RVI Processor Support

GRKERNSEC_CONFIG_VIRT_EPT\

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

First-gen/No Hardware Virtualization

GRKERNSEC_CONFIG_VIRT_SOFT\

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.

Virtualization Software

Choose between Xen, Xen PV, VMware, KVM, VirtualBox, or HyperV virtualization here.

Paravirtualized Xen

GRKERNSEC_CONFIG_VIRT_XEN_PV\

Choose this option if this kernel is running as a Paravirtualized Xen domU or dom0.
KERNEXEC on both i386 and x86_64 and UDEREF on x86_64, as well as RANDKSTACK will
not be enabled.

PVHVM/HVM Xen

GRKERNSEC_CONFIG_VIRT_XEN\

Choose this option if this kernel is running as a non-PV Xen domU or dom0.

VMWare

GRKERNSEC_CONFIG_VIRT_VMWARE\

Choose this option if this kernel is running as a VMWare guest or host.

KVM

GRKERNSEC_CONFIG_VIRT_KVM\

Choose this option if this kernel is running as a KVM guest or host.

VirtualBox

GRKERNSEC_CONFIG_VIRT_VIRTUALBOX\

Choose this option if this kernel is running as a VirtualBox guest or host.

Hyper-V

GRKERNSEC_CONFIG_VIRT_HYPERV\

Choose this option if this kernel is running as a Hyper-V guest.

Required Priorities

Choose between performance or security priorities here.

Performance

GRKERNSEC_CONFIG_PRIORITY_PERF\

Choose this option if performance is of highest priority for this deployment
of grsecurity.  Features like kernel stack clearing, clearing of structures
intended for userland, and freed memory sanitizing will be disabled.

Security

GRKERNSEC_CONFIG_PRIORITY_SECURITY\

Choose this option if security is of highest priority for this deployment of
grsecurity.  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 10% performance hit.

Default Special Groups

GID exempted from /proc restrictions

GRKERNSEC_PROC_GID\

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.

GID for TPE-untrusted users

GRKERNSEC_TPE_UNTRUSTED_GID\

Setting this GID determines what group TPE restrictions will be
*enabled* for.  If the sysctl option is enabled, a sysctl option
with name "tpe_gid" is created.

GID for TPE-trusted users

GRKERNSEC_TPE_TRUSTED_GID\

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.

GID for users with kernel-enforced SymlinksIfOwnerMatch

GRKERNSEC_SYMLINKOWN_GID\

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.

Customize Configuration

PaX

Enable various PaX features

PAX\

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.

PaX Control

Support soft mode

PAX_SOFTMODE\

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.

Use legacy ELF header marking

PAX_EI_PAX\

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.

Use ELF program header marking

PAX_PT_PAX_FLAGS\

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.

Use filesystem extended attributes marking

PAX_XATTR_PAX_FLAGS\

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.

MAC system integration

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.

none

PAX_NO_ACL_FLAGS\

direct

PAX_HAVE_ACL_FLAGS\

hook

PAX_HOOK_ACL_FLAGS\

Non-executable pages

Enforce non-executable pages

PAX_NOEXEC\

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.

Paging based non-executable pages

PAX_PAGEEXEC\

This implementation is based on the paging feature of the CPU.

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.

Segmentation based non-executable pages

PAX_SEGMEXEC\

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.

Emulate trampolines

PAX_EMUTRAMP\

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.

Automatically emulate sigreturn trampolines

PAX_EMUSIGRT\

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.

Restrict mprotect()

PAX_MPROTECT\

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.

Use legacy/compat protection demoting (read help)

PAX_MPROTECT_COMPAT\

The current implementation of PAX_MPROTECT denies RWX allocations/mprotects
by sending the proper error code to the application.  For some older
userland, this can cause problems with applications that assume such
allocations will not be prevented by PaX or SELinux and other access
control systems and have no fallback mechanisms.  For modern distros,
this option should generally be set to 'N'.

Allow ELF text relocations (read help)

PAX_ELFRELOCS\

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.

Allow ELF ET_EXEC text relocations

PAX_ETEXECRELOCS\

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.

Automatically emulate ELF PLT

PAX_EMUPLT\

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.

Emulate old glibc resolver stub

PAX_DLRESOLVE\

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.

Enforce non-executable kernel pages

PAX_KERNEXEC\

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 amd64, CONFIG_EFI enabled with "efi=old_map" on
the kernel command-line will result in an RWX physical map.

Likewise, the EFI runtime services are necessarily mapped as
RWX.  If CONFIG_EFI is enabled on an EFI-capable system, it
is recommended that you boot with "noefi" on the kernel
command-line if possible to eliminate the mapping.

Code Pointer Instrumentation Method

KERNEXEC on amd64 is not as secure as its i386 variant due to the
lack of certain processor features.  This option can bring back some
of the security by forcing all code pointers at runtime to fall into
kernel memory.  This is achieved via compile time instrumentation of
all code pointer dereferences (indirect calls and function returns).

While there are alternative mechanisms (SMEP, UDEREF) that can achieve
the same or even more, they also have their own drawbacks in terms of
performance impact and/or being processor dependent so this feature
offers a choice by having a low performance impact and being processor
independent.

If you enabled RAP (see PAX_RAP) and have an amd64 processor that does
not support SMEP then you must also enable a KERNEXEC code pointer
instrumentation method.

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.

none

PAX_KERNEXEC_PLUGIN_METHOD_NONE\

In case your processor supports Supervisor Mode Execution
Prevention (SMEP) you should choose this option to disable
compile time instrumentation.

Note that the kernel will refuse to boot if SMEP is not
supported by the processor or is disabled on the kernel
command line.

bts

PAX_KERNEXEC_PLUGIN_METHOD_BTS\

This method is compatible with binary only modules but has
a higher runtime overhead.

Minimum amount of memory reserved for module code

PAX_KERNEXEC_MODULE_TEXT\

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.

Address Space Layout Randomization

PAX_ASLR\

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

Randomize kernel stack base

PAX_RANDKSTACK\

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.

Randomize user stack and mmap() bases

PAX_RANDMMAP\

By saying Y here the kernel will randomize every task's userland
stack and use a randomized base address for mmap() requests that
do not specify one themselves.

The stack 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).

As a result of mmap randomization 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.

Miscellaneous hardening features

Sanitize all freed memory

PAX_MEMORY_SANITIZE\

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.

The slab sanitization feature excludes a few slab caches per default
for performance reasons.  To extend the feature to cover those as
well, pass "pax_sanitize_slab=full" as kernel command line parameter.

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 command line parameter
"pax_sanitize_slab=off".

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.

Sanitize kernel stack

PAX_MEMORY_STACKLEAK\

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.

Forcibly initialize local variables copied to userland

PAX_MEMORY_STRUCTLEAK\

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.

Prevent invalid userland pointer dereference

PAX_MEMORY_UDEREF\

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.

Another purpose of this feature is to prevent userland from accessing
kernel memory during speculative execution (CVE-2017-5754, Meltdown).
For best performance on i386 all userland should be recompiled with
-mno-tls-direct-seg-refs and libc should be a 'nosegneg' variant.

Note that when enabling this feature on guest kernels running on old
CPUs without hardware virtualization support there may be a huge
slowdown therefore you should not enable this feature for kernels
meant to run in such environments.

On X86_64 the kernel will make use of PCID support when available
(Intel's Westmere, Sandy Bridge, etc).

Prevent various kernel object reference counter overflows

PAX_REFCOUNT\

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.

Harden memory copies between kernel and userland

PAX_USERCOPY\

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.

Automatically constify eligible structures

PAX_CONSTIFY_PLUGIN\

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

Report code regions instrumented for writing to constified data

PAX_CONSTIFY_PLUGIN_VERBOSE\

Print out the start and end of code regions that are enabled to
modify otherwise read-only memory.

Prevent various integer overflows in function size parameters

PAX_SIZE_OVERFLOW\

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

If the recomputed argument does not fit the original type then the
event is logged.  If the pax_size_overflow_report_only parameter is
NOT passed on the kernel command line at boot then the triggering
process will also be killed.  Alternatively, the pax_so_report_only
parameter provides finer grained control over whether all events
should cause the triggering process to be killed or only those that
were not detected by the extra instrumentation (for more details
see PAX_SIZE_OVERFLOW_EXTRA).

Homepage: https://github.com/ephox-gcc-plugins/size_overflow
Blog: http://forums.grsecurity.net/viewtopic.php?f=7&t=3043

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.

Increase coverage of size overflow checking

PAX_SIZE_OVERFLOW_EXTRA\

By saying Y here the kernel will instrument more size argument
calculations that off-line static analysis tracked back through
indirect function calls, structure fields and global variables.

This greatly increases coverage and thus security however there
are also more false positives and the performance impact is higher
as well.

Log missing size overflow hash table entries

PAX_SIZE_OVERFLOW_HASHGEN\

By saying Y here the size overflow gcc plugin will perform data
flow analysis during the kernel build process to detect new code
that affects size calculations.  New discoveries are logged to
to stderr for later integration into the size overflow plugin's
metadata hash tables.  Unless you are developing this plugin or
are otherwise interested in instrumenting new code, you should
say N here.

Free more kernel memory after init

PAX_INITIFY\

The kernel has a mechanism to free up code and data memory that is
only used during kernel or module initialization.  Enabling this
feature will teach the compiler to find more such code and data
that can be freed after initialization.

Free more kernel memory after init (verbose mode)

PAX_INITIFY_VERBOSE\

Print all initified strings and all functions which should be
__init/__exit.

Note that the candidates identified for __init/__exit markings
depend on the current kernel configuration and thus should be
verified manually before the source code is patched.

Generate some entropy during boot and runtime

PAX_LATENT_ENTROPY\

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 (about 0.5%) 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!

Prevent code reuse attacks

PAX_RAP\

By saying Y here the kernel will check indirect control transfers
in order to detect and prevent attacks that try to hijack control
flow by overwriting code pointers.

If you have an amd64 processor that does not support SMEP then you
must also enable a KERNEXEC code pointer instrumentation method
(see PAX_KERNEXEC_PLUGIN).

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.

Forward edge defense (deterministic)

PAX_RAP_CALL\

Forward edge defense instrumentation method

Some processors are susceptible to certain speculative execution
based attacks.  This option selects the instrumentation kind for
the forward edge defense with different tradeoffs between security,
performance and information about control flow violations.

Note that each instrumentation method for the forward edge defense
provides the same security level for normal (non-speculative)
execution, they differ only under speculative execution on affected
processors.

Kernels built to run purely on AMD systems with an updated
microcode and CONFIG_RETPOLINE enabled should enable the "callabort"
method for improved performance and reporting ability.  Such systems
are not able to perform speculative ROP attacks in the kernel.

callabort

PAX_RAP_CALL_ABORT\

This instrumentation method provides the best performance
and is able to provide full details for control flow
violations but it may be susceptible to speculative
execution based attacks under certain circumstances.

callnospec

PAX_RAP_CALL_NOSPEC\

This instrumentation is safe from speculation based attacks
but has a worse performance impact and provides only partial
details for control flow violations (the unintended, possibly
hijacked, control flow target may not be discoverable).

Kernels built to run purely on AMD systems with an updated
microcode and CONFIG_RETPOLINE enabled should not enable this
option to benefit from improved performance and reporting
ability.  Such systems are not able to speculatively perform
ROP attacks in the kernel.

Note that this feature requires gcc 4.8 or newer.

Backward edge defense (deterministic)

PAX_RAP_RET\

Backward edge defense (probabilistic)

PAX_RAP_XOR\

Automatically protect kernel code vulnerable to Spectre v1

PAX_RESPECTRE_PLUGIN\

By saying Y here the compiler will automatically find and protect
kernel code that may be vulnerable to CVE-2017-5753 (Spectre v1).
The defense ensures that speculative array accesses use either
a properly bounded or non-speculated index.  There are two defense
types: index masking and fencing.  The former is preferred due to
its negligible performance impact but it is not always feasible to
use it so fencing is used in such cases.

While the performance impact of the instrumentation should be mostly
negligible (fencing is rarely used and even then its impact is quite
processor dependent), you should measure it on your particular
workload before deployment.

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.

Protect more kernel code vulnerable to Spectre v1

PAX_RESPECTRE_PLUGIN_LOOPINDEX\

By saying Y here the compiler will protect more kernel code from
Spectre v1 attacks where the potentially vulnerable instances depend
on a loop index variable and speculative loop overexecution.  In such
cases the processor can speculatively execute a loop more times than
the intended loop count which can result in speculative uses of
out-of-bound pointers and other invalid data.

As the number of such cases is over 5 times of the 'normal' Spectre
v1 instrumentation, the performance impact needs to be carefully
measured before enabling this option.

Automatically protect kernel code vulnerable to Spectre v4

PAX_RESPECTRE_PLUGIN_SSB\

By saying Y here the compiler will automatically find and protect
kernel code that may be vulnerable to CVE-2018-3639 (Spectre v4).
The defense is fencing that ensures that speculative loads of an
array index variable do not bypass earlier stores to the index.

Note that this defense does not apply to user programs therefore
if you want to protect them as well you must enable some form of
the SSBD defense instead, see the kernel documentation about
'spec_store_bypass_disable'.

Note that in order to reduce performance impact, the static analysis
is specifically tailored to finding problematic stores and loads
inside the same function only.  Nevertheless, you should measure its
performance impact before deployment and also compare it to that of
the full SSBD defense which also protects the kernel.

Protect more kernel code vulnerable to Spectre v4

PAX_RESPECTRE_PLUGIN_SSB_ALL\

By saying Y here the compiler will protect more kernel code from
Spectre v4 attacks where the potentially vulnerable instances can
cross function boundaries.

As the number of such cases is about 25 times of the 'normal' Spectre
v4 instrumentation, the performance impact needs to be carefully
measured before enabling this option.

Report code found to be potentially vulnerable to Spectre v1/v4

PAX_RESPECTRE_PLUGIN_VERBOSE\

Print out statements deemed vulnerable to Spectre v1/v4 along with
the chosen defense type during compilation.

Convert k*alloc allocations into their own slabs

PAX_AUTOSLAB_PLUGIN\

Convert generic memory allocations of candidate types into type
specific slab allocations.  This can help reduce memory fragmentation
and will stop the exploit technique that relies on type confusion
between objects of different types that would otherwise be allocated
from the same generic slab.

Note that autoslabs with live objects created by a kernel module
will not be destroyed when unloading the module, resulting in a small
memory leak on such module unloads.  Live objects at module unload
time will be logged; in most instances, this will point to real memory
leak bugs in the kernel.

Note that this feature requires gcc 4.6 or newer.

Convert small k*alloc allocations to local variables

PAX_AUTOSLAB_PLUGIN_AUTOSTACK\

Some generic memory allocations are equivalent to and thus can be
converted to a local variable when they meet certain criteria.

Report autoslab decisions

PAX_AUTOSLAB_PLUGIN_VERBOSE\

Print out when an autoslab conversion took place or why it did not.

Report some potential NULL pointer dereferences

PAX_REPORT_NULL_DEREF\

Report some NULL pointer dereferences that gcc was unable to eliminate
during optimization.  Note that these may or may not be real bugs but
are worth a look regardless as the code should at least be refactored.

Memory Protections

Deny reading/writing to /dev/kmem, /dev/mem, and /dev/port

GRKERNSEC_KMEM\

If you say Y here, /dev/kmem and /dev/mem won't be allowed to
be written to or read from to modify or leak the contents of the running
kernel.  /dev/port will also not be allowed to be opened, writing to
/dev/cpu/*/msr will be prevented, and support for kexec will be removed.
If you have module support disabled, enabling this will close up several
ways that are currently used to insert malicious code into the running
kernel.

Even with this feature enabled, we still highly recommend that
you use the RBAC system, as it is still possible for an attacker to
modify the running kernel through other more obscure methods.

Enabling this feature will prevent the "cpupower" and "powertop" tools
from working and excludes debugfs from being compiled into the kernel.

It is highly recommended that you say Y here if you meet all the
conditions above.

Restrict VM86 mode

GRKERNSEC_VM86\

If you say Y here, only processes with CAP_SYS_RAWIO will be able to
make use of a special execution mode on 32bit x86 processors called
Virtual 8086 (VM86) mode.  XFree86 may need vm86 mode for certain
video cards and will still work with this option enabled.  The purpose
of the option is to prevent exploitation of emulation errors in
virtualization of vm86 mode like the one discovered in VMWare in 2009.
Nearly all users should be able to enable this option.

Disable privileged I/O

GRKERNSEC_IO
Related sysctl variables:
:kernel.grsecurity.disable_priv_io

If you say Y here, all ioperm and iopl calls will return an error.
Ioperm and iopl can be used to modify the running kernel.
Unfortunately, some programs need this access to operate properly,
the most notable of which are XFree86 and hwclock.  hwclock can be
remedied by having RTC support in the kernel, so real-time 
clock support is enabled if this option is enabled, to ensure 
that hwclock operates correctly.  If hwclock still does not work,
either update udev or symlink /dev/rtc to /dev/rtc0.

If you're using XFree86 or a version of Xorg from 2012 or earlier,
you may not be able to boot into a graphical environment with this
option enabled.  In this case, you should use the RBAC system instead.

Harden BPF interpreter

GRKERNSEC_BPF_HARDEN\

Enabling this option will automatically configure the kernel's BPF
JIT with the most secure settings.

If you're using KERNEXEC, it's recommended that you enable this option
to supplement the hardening of the kernel.

Disable unprivileged PERF_EVENTS usage by default

GRKERNSEC_PERF_HARDEN\

If you say Y here, the range of acceptable values for the
/proc/sys/kernel/perf_event_paranoid sysctl will be expanded to allow and
default to a new value: 3.  When the sysctl is set to this value, no
unprivileged use of the PERF_EVENTS syscall interface will be permitted.

Though PERF_EVENTS can be used legitimately for performance monitoring
and low-level application profiling, it is forced on regardless of
configuration, has been at fault for several vulnerabilities, and
creates new opportunities for side channels and other information leaks.

This feature puts PERF_EVENTS into a secure default state and permits
the administrator to change out of it temporarily if unprivileged
application profiling is needed.

Insert random gaps between thread stacks

GRKERNSEC_RAND_THREADSTACK\

If you say Y here, a random-sized gap will be enforced between allocated
thread stacks.  Glibc's NPTL and other threading libraries that
pass MAP_STACK to the kernel for thread stack allocation are supported.
The implementation currently provides 8 bits of entropy for the gap.

Many distributions do not compile threaded remote services with the
-fstack-check argument to GCC, causing the variable-sized stack-based
allocator, alloca(), to not probe the stack on allocation.  This
permits an unbounded alloca() to skip over any guard page and potentially
modify another thread's stack reliably.  An enforced random gap
reduces the reliability of such an attack and increases the chance
that such a read/write to another thread's stack instead lands in
an unmapped area, causing a crash and triggering grsecurity's
anti-bruteforcing logic.

Harden ASLR against information leaks and entropy reduction

GRKERNSEC_PROC_MEMMAP\

If you say Y here, the /proc/<pid>/maps and /proc/<pid>/stat files will
give no information about the addresses of its mappings if
PaX features that rely on random addresses are enabled on the task.
In addition to sanitizing this information and disabling other
dangerous sources of information, this option causes reads of sensitive
/proc/<pid> entries where the file descriptor was opened in a different
task than the one performing the read.  Such attempts are logged.
This option also limits argv/env strings for suid/sgid binaries
to 512KB to prevent a complete exhaustion of the stack entropy provided
by ASLR.  Finally, it places an 8MB stack resource limit on suid/sgid
binaries to prevent alternative mmap layouts from being abused.

If you use PaX it is essential that you say Y here as it closes up
several holes that make full ASLR useless locally.

Prevent kernel stack overflows

GRKERNSEC_KSTACKOVERFLOW\

If you say Y here, the kernel's process stacks will be allocated
with vmalloc instead of the kernel's default allocator.  This
introduces guard pages that in combination with the alloca checking
of the STACKLEAK feature and removal of thread_info from the kernel
stack prevents all forms of kernel process stack overflow abuse.
Note that this is different from kernel stack buffer overflows.

Deter exploit bruteforcing

GRKERNSEC_BRUTE
Related sysctl variables:
:kernel.grsecurity.deter_bruteforce

If you say Y here, attempts to bruteforce exploits against forking
daemons such as apache or sshd, as well as against suid/sgid binaries
will be deterred.  When a child of a forking daemon is killed by PaX
or crashes due to an illegal instruction or other suspicious signal,
the parent process will be delayed 30 seconds upon every subsequent
fork until the administrator is able to assess the situation and
restart the daemon.
In the suid/sgid case, the attempt is logged, the user has all their
existing instances of the suid/sgid binary terminated and will
be unable to execute any suid/sgid binaries for 15 minutes.

It is recommended that you also enable signal logging in the auditing
section so that logs are generated when a process triggers a suspicious
signal.
If the sysctl option is enabled, a sysctl option with name
"deter_bruteforce" is created.

Harden module auto-loading

GRKERNSEC_MODHARDEN\

If you say Y here, module auto-loading in response to use of some
feature implemented by an unloaded module will be restricted to
root users.  Enabling this option helps defend against attacks 
by unprivileged users who abuse the auto-loading behavior to 
cause a vulnerable module to load that is then exploited.

If this option prevents a legitimate use of auto-loading for a 
non-root user, the administrator can execute modprobe manually 
with the exact name of the module mentioned in the alert log.
Alternatively, the administrator can add the module to the list
of modules loaded at boot by modifying init scripts.

Modification of init scripts will most likely be needed on 
Ubuntu servers with encrypted home directory support enabled,
as the first non-root user logging in will cause the ecb(aes),
ecb(aes)-all, cbc(aes), and cbc(aes)-all  modules to be loaded.

Hide kernel symbols

GRKERNSEC_HIDESYM\

If you say Y here, getting information on loaded modules, and
displaying all kernel symbols through a syscall will be restricted
to users with CAP_SYS_MODULE.  For software compatibility reasons,
/proc/kallsyms will be restricted to the root user.  The RBAC
system can hide that entry even from root.

This option also prevents leaking of kernel addresses through
several /proc entries.

Note that this option is only effective provided the following
conditions are met:
1) The kernel using grsecurity is not precompiled by some distribution
2) You have also enabled GRKERNSEC_DMESG
3) You are using the RBAC system and hiding other files such as your
   kernel image and System.map.  Alternatively, enabling this option
   causes the permissions on /boot, /lib/modules, and the kernel
   source directory to change at compile time to prevent 
   reading by non-root users.
If the above conditions are met, this option will aid in providing a
useful protection against local kernel exploitation of overflows
and arbitrary read/write vulnerabilities.

It is highly recommended that you enable GRKERNSEC_PERF_HARDEN
in addition to this feature.

Randomize layout of sensitive kernel structures

GRKERNSEC_RANDSTRUCT\

If you say Y here, the layouts of a number of sensitive kernel
structures (task, fs, cred, etc) and all structures composed entirely
of function pointers (aka "ops" structs) will be randomized at compile-time.
This can introduce the requirement of an additional infoleak
vulnerability for exploits targeting these structure types.

Enabling this feature will introduce some performance impact, slightly
increase memory usage, and prevent the use of forensic tools like
Volatility against the system (unless the kernel source tree isn't
cleaned after kernel installation).

The seed used for compilation is located at scripts/gcc-plugins/randomize_layout_seed.h.
It remains after a make clean to allow for external modules to be compiled
with the existing seed and will be removed by a make mrproper or
make distclean.

Note that the implementation requires gcc 4.6.4. or newer.  You may need
to install the supporting headers explicitly in addition to the normal
gcc package.

Use cacheline-aware structure randomization

GRKERNSEC_RANDSTRUCT_PERFORMANCE\

If you say Y here, the RANDSTRUCT randomization will make a best effort
at restricting randomization to cacheline-sized groups of elements.
This reduces the performance hit of RANDSTRUCT at the cost of weakened
randomization.

Active kernel exploit response

GRKERNSEC_KERN_LOCKOUT\

If you say Y here, when a PaX alert is triggered due to suspicious
activity in the kernel (from KERNEXEC/UDEREF/USERCOPY)
or an OOPS occurs due to bad memory accesses, instead of just
terminating the offending process (and potentially allowing
a subsequent exploit from the same user), we will take one of two
actions:
 If the user was root, we will panic the system
 If the user was non-root, we will log the attempt, terminate
 all processes owned by the user, then prevent them from creating
 any new processes until the system is restarted
This deters repeated kernel exploitation/bruteforcing attempts
and is useful for later forensics.

Old ARM userland compatibility

GRKERNSEC_OLD_ARM_USERLAND\

If you say Y here, stubs of executable code to perform such operations
as "compare-exchange" will be placed at fixed locations in the ARM vector
table.  This is unfortunately needed for old ARM userland meant to run
across a wide range of processors.  Without this option enabled,
the get_tls and data memory barrier stubs will be emulated by the kernel,
which is enough for Linaro userlands or other userlands designed for v6
and newer ARM CPUs.  It's recommended that you try without this option enabled
first, and only enable it if your userland does not boot (it will likely fail
at init time).

Role Based Access Control Options

Disable RBAC system

GRKERNSEC_NO_RBAC\

If you say Y here, the /dev/grsec device will be removed from the kernel,
preventing the RBAC system from being enabled.  You should only say Y
here if you have no intention of using the RBAC system, so as to prevent
an attacker with root access from misusing the RBAC system to hide files
and processes when loadable module support and /dev/[k]mem have been
locked down.

Hide kernel processes

GRKERNSEC_ACL_HIDEKERN\

If you say Y here, all kernel threads will be hidden to all
processes but those whose subject has the "view hidden processes"
flag.

Maximum tries before password lockout

GRKERNSEC_ACL_MAXTRIES\

This option enforces the maximum number of times a user can attempt
to authorize themselves with the grsecurity RBAC system before being
denied the ability to attempt authorization again for a specified time.
The lower the number, the harder it will be to brute-force a password.

Time to wait after max password tries, in seconds

GRKERNSEC_ACL_TIMEOUT\

This option specifies the time the user must wait after attempting to
authorize to the RBAC system with the maximum number of invalid
passwords.  The higher the number, the harder it will be to brute-force
a password.

Filesystem Protections

Proc restrictions

GRKERNSEC_PROC\

If you say Y here, the permissions of the /proc filesystem
will be altered to enhance system security and privacy.  You MUST
choose either a user only restriction or a user and group restriction.
Depending upon the option you choose, you can either restrict users to
see only the processes they themselves run, or choose a group that can
view all processes and files normally restricted to root if you choose
the "restrict to user only" option.  NOTE: If you're running identd or
ntpd as a non-root user, you will have to run it as the group you
specify here.

Restrict /proc to user only

GRKERNSEC_PROC_USER\

If you say Y here, non-root users will only be able to view their own
processes, and restricts them from viewing network-related information,
and viewing kernel symbol and module information.

Allow special group

GRKERNSEC_PROC_USERGROUP\

If you say Y here, you will be able to select a group that will be
able to view all processes and network-related information.  If you've
enabled GRKERNSEC_HIDESYM, kernel and symbol information may still
remain hidden.  This option is useful if you want to run identd as
a non-root user.  The group you select may also be chosen at boot time
via "grsec_proc_gid=" on the kernel commandline.

GID exempted from /proc restrictions

GRKERNSEC_PROC_GID\

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.

Additional restrictions

GRKERNSEC_PROC_ADD\

If you say Y here, additional restrictions will be placed on
/proc that keep normal users from viewing device information and 
slabinfo information that could be useful for exploits.

Linking restrictions

GRKERNSEC_LINK
Related sysctl variables:
:kernel.grsecurity.linking_restrictions

If you say Y here, /tmp race exploits will be prevented, since users
will no longer be able to follow symlinks owned by other users in
world-writable +t directories (e.g. /tmp), unless the owner of the
symlink is the owner of the directory. users will also not be
able to hardlink to files they do not own.  If the sysctl option is
enabled, a sysctl option with name "linking_restrictions" is created.

Kernel-enforced SymlinksIfOwnerMatch

GRKERNSEC_SYMLINKOWN\
Related sysctl variables:\
:kernel.grsecurity.enforce_symlinksifowner: kernel.grsecurity.symlinkown_gid

Apache's SymlinksIfOwnerMatch option has an inherent race condition
that prevents it from being used as a security feature.  As Apache
verifies the symlink by performing a stat() against the target of
the symlink before it is followed, an attacker can setup a symlink
to point to a same-owned file, then replace the symlink with one
that targets another user's file just after Apache "validates" the
symlink -- a classic TOCTOU race.  If you say Y here, a complete,
race-free replacement for Apache's "SymlinksIfOwnerMatch" option
will be in place for the group you specify. If the sysctl option
is enabled, a sysctl option with name "enforce_symlinksifowner" is
created.

GID for users with kernel-enforced SymlinksIfOwnerMatch

GRKERNSEC_SYMLINKOWN_GID\

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.

FIFO restrictions

GRKERNSEC_FIFO
Related sysctl variables:
:kernel.grsecurity.fifo_restrictions

If you say Y here, users will not be able to write to FIFOs they don't
own in world-writable +t directories (e.g. /tmp), unless the owner of
the FIFO is the same owner of the directory it's held in.  If the sysctl
option is enabled, a sysctl option with name "fifo_restrictions" is
created.

Sysfs/debugfs restriction

GRKERNSEC_SYSFS_RESTRICT
Related sysctl variables:
:kernel.grsecurity.enforce_sysfs_restrict

If you say Y here, sysfs (the pseudo-filesystem mounted at /sys) and
any filesystem normally mounted under it (e.g. debugfs) will be
mostly accessible only by root.  These filesystems generally provide access
to hardware and debug information that isn't appropriate for unprivileged
users of the system.  Sysfs and debugfs have also become a large source
of new vulnerabilities, ranging from infoleaks to local compromise.
There has been very little oversight with an eye toward security involved
in adding new exporters of information to these filesystems, so their
use is discouraged.
For reasons of compatibility, a few directories have been whitelisted
for access by non-root users:
/sys/fs/selinux
/sys/fs/fuse
/sys/devices/system/cpu

If the sysctl option is enabled, a sysctl option with name
"enforce_sysfs_restrict" is created to control the sysfs side
of this protection at runtime.

At kernel boot time, the grsec_sysfs_restrict=0 option can be
used on the kernel commandline to disable both the sysfs and
debugfs aspects of this feature.

Please note that for backward compatibility reasons, the enforce_sysfs_restrict
option will default to on regardless of any other grsecurity settings.

Allow special group to bypass sysfs restrictions

GRKERNSEC_SYSFS_RESTRICT_GROUP
Related sysctl variables:
:kernel.grsecurity.sysfs_restrict_bypass_gid

If you say Y here, you will be able to select a group that will be
able to bypass the sysfs restrictions of GRKERNSEC_SYSFS_RESTRICT.
While we aim to whitelist obviously safe entries for compatibility
purposes, this may not always be possible, so this additional group
can be used to fill that compatibility need if it arises.

GID for users that bypass sysfs restrictions

GRKERNSEC_SYSFS_RESTRICT_GID\

Setting this GID determines what group bypassing of sysfs restrictions
will be permitted for. If the sysctl option is enabled, a sysctl option
with name "sysfs_restrict_bypass_gid" is created.

Runtime read-only mount protection

GRKERNSEC_ROFS
Related sysctl variables:
:kernel.grsecurity.romount_protect

If you say Y here, a sysctl option with name "romount_protect" will
be created.  By setting this option to 1 at runtime, filesystems
will be protected in the following ways:
* No new writable mounts will be allowed
* Existing read-only mounts won't be able to be remounted read/write
* Write operations will be denied on all block devices
This option acts independently of grsec_lock: once it is set to 1,
it cannot be turned off.  Therefore, please be mindful of the resulting
behavior if this option is enabled in an init script on a read-only
filesystem.
Also be aware that as with other root-focused features, GRKERNSEC_KMEM
and GRKERNSEC_IO should be enabled and module loading disabled via
config or at runtime.
This feature is mainly intended for secure embedded systems.

Eliminate stat/notify-based device sidechannels

GRKERNSEC_DEVICE_SIDECHANNEL\

If you say Y here, timing analyses on block or character
devices like /dev/ptmx using stat or inotify/dnotify/fanotify
will be thwarted for unprivileged users.  If a process without
CAP_MKNOD stats such a device, the last access and last modify times
will match the device's create time.  No access or modify events
will be triggered through inotify/dnotify/fanotify for such devices.
This feature will prevent attacks that may at a minimum
allow an attacker to determine the administrator's password length.

Chroot jail restrictions

GRKERNSEC_CHROOT\

If you say Y here, you will be able to choose several options that will
make breaking out of a chrooted jail much more difficult.  If you
encounter no software incompatibilities with the following options, it
is recommended that you enable each one.

Note that the chroot restrictions are not intended to apply to "chroots"
to directories that are simple bind mounts of the global root filesystem.
For several other reasons, a user shouldn't expect any significant
security by performing such a chroot.

Deny mounts

GRKERNSEC_CHROOT_MOUNT
Related sysctl variables:
:kernel.grsecurity.chroot_deny_mount

If you say Y here, processes inside a chroot will not be able to
mount or remount filesystems.  If the sysctl option is enabled, a
sysctl option with name "chroot_deny_mount" is created.

Deny double-chroots

GRKERNSEC_CHROOT_DOUBLE
Related sysctl variables:
:kernel.grsecurity.chroot_deny_chroot

If you say Y here, processes inside a chroot will not be able to chroot
again outside the chroot.  This is a widely used method of breaking
out of a chroot jail and should not be allowed.  If the sysctl 
option is enabled, a sysctl option with name 
"chroot_deny_chroot" is created.

Deny pivot_root in chroot

GRKERNSEC_CHROOT_PIVOT
Related sysctl variables:
:kernel.grsecurity.chroot_deny_pivot

If you say Y here, processes inside a chroot will not be able to use
a function called pivot_root() that was introduced in Linux 2.3.41.  It
works similar to chroot in that it changes the root filesystem.  This
function could be misused in a chrooted process to attempt to break out
of the chroot, and therefore should not be allowed.  If the sysctl
option is enabled, a sysctl option with name "chroot_deny_pivot" is
created.

Enforce chdir(

GRKERNSEC_CHROOT_CHDIR
Related sysctl variables:
:kernel.grsecurity.chroot_enforce_chdir

If you say Y here, the current working directory of all newly-chrooted
applications will be set to the the root directory of the chroot.
The man page on chroot(2) states:
Note that this call does not change  the  current  working
directory,  so  that `.' can be outside the tree rooted at
`/'.  In particular, the  super-user  can  escape  from  a
`chroot jail' by doing `mkdir foo; chroot foo; cd ..'.

It is recommended that you say Y here, since it's not known to break
any software.  If the sysctl option is enabled, a sysctl option with
name "chroot_enforce_chdir" is created.

Deny (f)chmod +s

GRKERNSEC_CHROOT_CHMOD
Related sysctl variables:
:kernel.grsecurity.chroot_deny_chmod

If you say Y here, processes inside a chroot will not be able to chmod
or fchmod files to make them have suid or sgid bits.  This protects
against another published method of breaking a chroot.  If the sysctl
option is enabled, a sysctl option with name "chroot_deny_chmod" is
created.

Deny fchdir and fhandle out of chroot

GRKERNSEC_CHROOT_FCHDIR
Related sysctl variables:
:kernel.grsecurity.chroot_deny_fchdir

If you say Y here, a well-known method of breaking chroots by fchdir'ing
to a file descriptor of the chrooting process that points to a directory
outside the filesystem will be stopped.  This option also prevents use of
the recently-created syscall for opening files by a guessable "file handle"
inside a chroot, as well as accessing relative paths outside of a
directory passed in via file descriptor with openat and similar syscalls.
If the sysctl option is enabled, a sysctl option with name "chroot_deny_fchdir"
is created.

Deny mknod

GRKERNSEC_CHROOT_MKNOD
Related sysctl variables:
:kernel.grsecurity.chroot_deny_mknod

If you say Y here, processes inside a chroot will not be allowed to
mknod.  The problem with using mknod inside a chroot is that it
would allow an attacker to create a device entry that is the same
as one on the physical root of your system, which could range from
anything from the console device to a device for your harddrive (which
they could then use to wipe the drive or steal data).  It is recommended
that you say Y here, unless you run into software incompatibilities.
If the sysctl option is enabled, a sysctl option with name
"chroot_deny_mknod" is created.

Deny shmat() out of chroot

GRKERNSEC_CHROOT_SHMAT
Related sysctl variables:
:kernel.grsecurity.chroot_deny_shmat

If you say Y here, processes inside a chroot will not be able to attach
to shared memory segments that were created outside of the chroot jail.
It is recommended that you say Y here.  If the sysctl option is enabled,
a sysctl option with name "chroot_deny_shmat" is created.

Deny access to abstract AF_UNIX sockets out of chroot

GRKERNSEC_CHROOT_UNIX
Related sysctl variables:
:kernel.grsecurity.chroot_deny_unix

If you say Y here, processes inside a chroot will not be able to
connect to abstract (meaning not belonging to a filesystem) Unix
domain sockets that were bound outside of a chroot.  It is recommended
that you say Y here.  If the sysctl option is enabled, a sysctl option
with name "chroot_deny_unix" is created.

Protect outside processes

GRKERNSEC_CHROOT_FINDTASK
Related sysctl variables:
:kernel.grsecurity.chroot_findtask

If you say Y here, processes inside a chroot will not be able to
kill, send signals with fcntl, ptrace, capget, getpgid, setpgid, 
getsid, or view any process outside of the chroot.  If the sysctl
option is enabled, a sysctl option with name "chroot_findtask" is
created.

Restrict priority changes

GRKERNSEC_CHROOT_NICE
Related sysctl variables:
:kernel.grsecurity.chroot_restrict_nice

If you say Y here, processes inside a chroot will not be able to raise
the priority of processes in the chroot, or alter the priority of
processes outside the chroot.  This provides more security than simply
removing CAP_SYS_NICE from the process' capability set.  If the
sysctl option is enabled, a sysctl option with name "chroot_restrict_nice"
is created.

Deny sysctl writes

GRKERNSEC_CHROOT_SYSCTL
Related sysctl variables:
:kernel.grsecurity.chroot_deny_sysctl

If you say Y here, an attacker in a chroot will not be able to
write to sysctl entries, either by sysctl(2) or through a /proc
interface.  It is strongly recommended that you say Y here. If the
sysctl option is enabled, a sysctl option with name
"chroot_deny_sysctl" is created.

Deny bad renames

GRKERNSEC_CHROOT_RENAME
Related sysctl variables:
:kernel.grsecurity.chroot_deny_bad_rename

If you say Y here, an attacker in a chroot will not be able to
abuse the ability to create double chroots to break out of the
chroot by exploiting a race condition between a rename of a directory
within a chroot against an open of a symlink with relative path
components.  This feature will likewise prevent an accomplice outside
a chroot from enabling a user inside the chroot to break out and make
use of their credentials on the global filesystem.  Enabling this
feature is essential to prevent root users from breaking out of a
chroot. If the sysctl option is enabled, a sysctl option with name
"chroot_deny_bad_rename" is created.

Capability restrictions

GRKERNSEC_CHROOT_CAPS
Related sysctl variables:
:kernel.grsecurity.chroot_caps

If you say Y here, the capabilities on all processes within a
chroot jail will be lowered to stop module insertion, raw i/o,
system and net admin tasks, rebooting the system, modifying immutable
files, modifying IPC owned by another, and changing the system time.
This is left an option because it can break some apps.  Disable this
if your chrooted apps are having problems performing those kinds of
tasks.  If the sysctl option is enabled, a sysctl option with
name "chroot_caps" is created.

Exempt initrd tasks from restrictions

GRKERNSEC_CHROOT_INITRD\

If you say Y here, tasks started prior to init will be exempted from
grsecurity's chroot restrictions.  This option is mainly meant to
resolve Plymouth's performing privileged operations unnecessarily
in a chroot.

Kernel Auditing

Single group for auditing

GRKERNSEC_AUDIT_GROUP\
Related sysctl variables:\
:kernel.grsecurity.audit_gid: kernel.grsecurity.audit_group

If you say Y here, the exec and chdir logging features will only operate
on a group you specify.  This option is recommended if you only want to
watch certain users instead of having a large amount of logs from the
entire system.  If the sysctl option is enabled, a sysctl option with
name "audit_group" is created.

GID for auditing

GRKERNSEC_AUDIT_GID\

Exec logging

GRKERNSEC_EXECLOG
Related sysctl variables:
:kernel.grsecurity.exec_logging

If you say Y here, all execve() calls will be logged (since the
other exec*() calls are frontends to execve(), all execution
will be logged).  Useful for shell-servers that like to keep track
of their users.  If the sysctl option is enabled, a sysctl option with
name "exec_logging" is created.
WARNING: This option when enabled will produce a LOT of logs, especially
on an active system.

Resource logging

GRKERNSEC_RESLOG
Related sysctl variables:
:kernel.grsecurity.resource_logging

If you say Y here, all attempts to overstep resource limits will
be logged with the resource name, the requested size, and the current
limit.  It is highly recommended that you say Y here.  If the sysctl
option is enabled, a sysctl option with name "resource_logging" is
created.  If the RBAC system is enabled, the sysctl value is ignored.

Log execs within chroot

GRKERNSEC_CHROOT_EXECLOG
Related sysctl variables:
:kernel.grsecurity.chroot_execlog

If you say Y here, all executions inside a chroot jail will be logged
to syslog.  This can cause a large amount of logs if certain
applications (eg. djb's daemontools) are installed on the system, and
is therefore left as an option.  If the sysctl option is enabled, a
sysctl option with name "chroot_execlog" is created.

Ptrace logging

GRKERNSEC_AUDIT_PTRACE
Related sysctl variables:
:kernel.grsecurity.audit_ptrace

If you say Y here, all attempts to attach to a process via ptrace
will be logged.  If the sysctl option is enabled, a sysctl option
with name "audit_ptrace" is created.

Chdir logging

GRKERNSEC_AUDIT_CHDIR
Related sysctl variables:
:kernel.grsecurity.audit_chdir

If you say Y here, all chdir() calls will be logged.  If the sysctl
option is enabled, a sysctl option with name "audit_chdir" is created.

(Un)Mount logging

GRKERNSEC_AUDIT_MOUNT
Related sysctl variables:
:kernel.grsecurity.audit_mount

If you say Y here, all mounts and unmounts will be logged.  If the
sysctl option is enabled, a sysctl option with name "audit_mount" is
created.

Only log (un)mounts for the initial mount namespace

GRKERNSEC_AUDIT_MOUNT_INITNS_ONLY\

If you say Y here, GRKERNSEC_AUDIT_MOUNT's behavior will be modified such
that only mounts/unmounts in the initial mount namespace will be logged.
This will eliminate noise from systemd and other facilities that create
mounts (generally for security purposes) within private mount namespaces
for specific services that have opted in.

Signal logging

GRKERNSEC_SIGNAL
Related sysctl variables:
:kernel.grsecurity.signal_logging

If you say Y here, certain important signals will be logged, such as
SIGSEGV, which will as a result inform you of when a error in a program
occurred, which in some cases could mean a possible exploit attempt.
If the sysctl option is enabled, a sysctl option with name
"signal_logging" is created.

Fork failure logging

GRKERNSEC_FORKFAIL
Related sysctl variables:
:kernel.grsecurity.forkfail_logging

If you say Y here, all failed fork() attempts will be logged.
This could suggest a fork bomb, or someone attempting to overstep
their process limit.  If the sysctl option is enabled, a sysctl option
with name "forkfail_logging" is created.

Time change logging

GRKERNSEC_TIME
Related sysctl variables:
:kernel.grsecurity.timechange_logging

If you say Y here, any changes of the system clock will be logged.
If the sysctl option is enabled, a sysctl option with name
"timechange_logging" is created.

/proc//ipaddr support

GRKERNSEC_PROC_IPADDR\

If you say Y here, a new entry will be added to each /proc/<pid>
directory that contains the IP address of the person using the task.
The IP is carried across local TCP and AF_UNIX stream sockets.
This information can be useful for IDS/IPSes to perform remote response
to a local attack.  The entry is readable by only the owner of the
process (and root if he has CAP_DAC_OVERRIDE, which can be removed via
the RBAC system), and thus does not create privacy concerns.

Denied RWX mmap/mprotect logging

GRKERNSEC_RWXMAP_LOG
Related sysctl variables:
:kernel.grsecurity.rwxmap_logging

If you say Y here, calls to mmap() and mprotect() with explicit
usage of PROT_WRITE and PROT_EXEC together will be logged when
denied by the PAX_MPROTECT feature.  This feature will also
log other problematic scenarios that can occur when PAX_MPROTECT
is enabled on a binary, like textrels and PT_GNU_STACK.  If the 
sysctl option is enabled, a sysctl option with name "rwxmap_logging"
is created.

Executable Protections

Dmesg(8) restriction

GRKERNSEC_DMESG
Related sysctl variables:
:kernel.grsecurity.dmesg

If you say Y here, non-root users will not be able to use dmesg(8)
to view the contents of the kernel's circular log buffer.
The kernel's log buffer often contains kernel addresses and other
identifying information useful to an attacker in fingerprinting a
system for a targeted exploit.
If the sysctl option is enabled, a sysctl option with name "dmesg" is
created.

Deter ptrace-based process snooping

GRKERNSEC_HARDEN_PTRACE
Related sysctl variables:
:kernel.grsecurity.harden_ptrace

If you say Y here, TTY sniffers and other malicious monitoring
programs implemented through ptrace will be defeated.  If you
have been using the RBAC system, this option has already been
enabled for several years for all users, with the ability to make
fine-grained exceptions.

This option only affects the ability of non-root users to ptrace
processes that are not a descendent of the ptracing process.
This means that strace ./binary and gdb ./binary will still work,
but attaching to arbitrary processes will not.  If the sysctl
option is enabled, a sysctl option with name "harden_ptrace" is
created.

Require read access to ptrace sensitive binaries

GRKERNSEC_PTRACE_READEXEC
Related sysctl variables:
:kernel.grsecurity.ptrace_readexec

If you say Y here, unprivileged users will not be able to ptrace unreadable
binaries.  This option is useful in environments that
remove the read bits (e.g. file mode 4711) from suid binaries to
prevent infoleaking of their contents.  This option adds
consistency to the use of that file mode, as the binary could normally
be read out when run without privileges while ptracing.

If the sysctl option is enabled, a sysctl option with name "ptrace_readexec"
is created.

Enforce consistent multithreaded privileges

GRKERNSEC_SETXID
Related sysctl variables:
:kernel.grsecurity.consistent_setxid

If you say Y here, a change from a root uid to a non-root uid
in a multithreaded application will cause the resulting uids,
gids, supplementary groups, and capabilities in that thread
to be propagated to the other threads of the process.  In most
cases this is unnecessary, as glibc will emulate this behavior
on behalf of the application.  Other libcs do not act in the
same way, allowing the other threads of the process to continue
running with root privileges.  If the sysctl option is enabled,
a sysctl option with name "consistent_setxid" is created.

Disallow access to overly-permissive IPC objects

GRKERNSEC_HARDEN_IPC
Related sysctl variables:
:kernel.grsecurity.harden_ipc

If you say Y here, access to overly-permissive IPC objects (shared
memory, message queues, and semaphores) will be denied for processes
given the following criteria beyond normal permission checks:
1) If the IPC object is world-accessible and the euid doesn't match
   that of the creator or current uid for the IPC object
2) If the IPC object is group-accessible and the egid doesn't
   match that of the creator or current gid for the IPC object
It's a common error to grant too much permission to these objects,
with impact ranging from denial of service and information leaking to
privilege escalation.  This feature was developed in response to
research by Tim Brown:
http://labs.portcullis.co.uk/whitepapers/memory-squatting-attacks-on-system-v-shared-memory/
who found hundreds of such insecure usages.  Processes with
CAP_IPC_OWNER are still permitted to access these IPC objects.
If the sysctl option is enabled, a sysctl option with name
"harden_ipc" is created.

Disallow unprivileged use of command injection

GRKERNSEC_HARDEN_TTY
Related sysctl variables:
:kernel.grsecurity.harden_tty

If you say Y here, the ability to use the TIOCSTI ioctl for
terminal command injection will be denied for unprivileged users.
There are very few legitimate uses for this functionality and it
has made vulnerabilities in several 'su'-like programs possible in
the past.  Even without these vulnerabilities, it provides an
attacker with an easy mechanism to move laterally among other
processes within the same user's compromised session.
By default, Linux allows unprivileged use of command injection as
long as the injection is being performed into the same tty session.
This feature makes that case the same as attempting to inject into
another session, making any TIOCSTI use require CAP_SYS_ADMIN.
If the sysctl option is enabled, a sysctl option with name
"harden_tty" is created.

Disable ability of suid root apps to execute unsafe files

GRKERNSEC_SUID_NO_UNPRIV_EXEC\

If you say Y here, suid root applications will not be able to mmap
executable or execute files world-writable or not owned by root.
This addresses both an exploitation technique (e.g. the struct
service_user overwrite in Qualys' CVE-2021-3156 Sudo exploit) as
well as a vulnerability class that has appeared in suid root
executables in the past (e.g. CVE-2017-4915).  If the sysctl
option is enabled, a sysctl option with name "suid_no_unpriv_exec"
is created.

Trusted Path Execution (TPE)

GRKERNSEC_TPE\
Related sysctl variables:\
:kernel.grsecurity.tpe: kernel.grsecurity.tpe_gid

If you say Y here, you will be able to choose a gid to add to the
supplementary groups of users you want to mark as "untrusted."
These users will not be able to execute any files that are not in
root-owned directories writable only by root.  If the sysctl option
is enabled, a sysctl option with name "tpe" is created.

Partially restrict all non-root users

GRKERNSEC_TPE_ALL
Related sysctl variables:
:kernel.grsecurity.tpe_restrict_all

If you say Y here, all non-root users will be covered under
a weaker TPE restriction.  This is separate from, and in addition to,
the main TPE options that you have selected elsewhere.  Thus, if a
"trusted" GID is chosen, this restriction applies to even that GID.
Under this restriction, all non-root users will only be allowed to
execute files in directories they own that are not group or
world-writable, or in directories owned by root and writable only by
root.  If the sysctl option is enabled, a sysctl option with name
"tpe_restrict_all" is created.

Invert GID option

GRKERNSEC_TPE_INVERT
Related sysctl variables:
:kernel.grsecurity.tpe_invert

If you say Y here, the group you specify in the TPE configuration will
decide what group TPE restrictions will be *disabled* for.  This
option is useful if you want TPE restrictions to be applied to most
users on the system.  If the sysctl option is enabled, a sysctl option
with name "tpe_invert" is created.  Unlike other sysctl options, this
entry will default to on for backward-compatibility.

GID for TPE-untrusted users

GRKERNSEC_TPE_UNTRUSTED_GID\

Setting this GID determines what group TPE restrictions will be
*enabled* for.  If the sysctl option is enabled, a sysctl option
with name "tpe_gid" is created.

GID for TPE-trusted users

GRKERNSEC_TPE_TRUSTED_GID\

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.

Network Protections

TCP/UDP blackhole and LAST_ACK DoS prevention

GRKERNSEC_BLACKHOLE\
Related sysctl variables:\
:kernel.grsecurity.ip_blackhole: kernel.grsecurity.lastack_retries

If you say Y here, neither TCP resets nor ICMP
destination-unreachable packets will be sent in response to packets
sent to ports for which no associated listening process exists.
It will also prevent the sending of ICMP protocol unreachable packets
in response to packets with unknown protocols.
This feature supports both IPV4 and IPV6 and exempts the 
loopback interface from blackholing.  Enabling this feature 
makes a host more resilient to DoS attacks and reduces network
visibility against scanners.

The blackhole feature as-implemented is equivalent to the FreeBSD
blackhole feature, as it prevents RST responses to all packets, not
just SYNs.  Under most application behavior this causes no
problems, but applications (like haproxy) may not close certain
connections in a way that cleanly terminates them on the remote
end, leaving the remote host in LAST_ACK state.  Because of this
side-effect and to prevent intentional LAST_ACK DoSes, this
feature also adds automatic mitigation against such attacks.
The mitigation drastically reduces the amount of time a socket
can spend in LAST_ACK state.  If you're using haproxy and not
all servers it connects to have this option enabled, consider
disabling this feature on the haproxy host.

If the sysctl option is enabled, two sysctl options with names
"ip_blackhole" and "lastack_retries" will be created.
While "ip_blackhole" takes the standard zero/non-zero on/off
toggle, "lastack_retries" uses the same kinds of values as
"tcp_retries1" and "tcp_retries2".  The default value of 4
prevents a socket from lasting more than 45 seconds in LAST_ACK
state.

Disable TCP Simultaneous Connect

GRKERNSEC_NO_SIMULT_CONNECT\

If you say Y here, a feature by Willy Tarreau will be enabled that
removes a weakness in Linux's strict implementation of TCP that
allows two clients to connect to each other without either entering
a listening state.  The weakness allows an attacker to easily prevent
a client from connecting to a known server provided the source port
for the connection is guessed correctly.

As the weakness could be used to prevent an antivirus or IPS from
fetching updates, or prevent an SSL gateway from fetching a CRL,
it should be eliminated by enabling this option.  Though Linux is
one of few operating systems supporting simultaneous connect, it
has no legitimate use in practice and is rarely supported by firewalls.

Socket restrictions

GRKERNSEC_SOCKET\

If you say Y here, you will be able to choose from several options.
If you assign a GID on your system and add it to the supplementary
groups of users you want to restrict socket access to, this patch
will perform up to three things, based on the option(s) you choose.

Deny any sockets to group

GRKERNSEC_SOCKET_ALL\
Related sysctl variables:\
:kernel.grsecurity.socket_all: kernel.grsecurity.socket_all_gid

If you say Y here, you will be able to choose a GID of whose users will
be unable to connect to other hosts from your machine or run server
applications from your machine.  If the sysctl option is enabled, a
sysctl option with name "socket_all" is created.

GID to deny all sockets for

GRKERNSEC_SOCKET_ALL_GID\

Here you can choose the GID to disable socket access for. Remember to
add the users you want socket access disabled for to the GID
specified here.  If the sysctl option is enabled, a sysctl option
with name "socket_all_gid" is created.

Deny client sockets to group

GRKERNSEC_SOCKET_CLIENT\
Related sysctl variables:\
:kernel.grsecurity.socket_client: kernel.grsecurity.socket_client_gid

If you say Y here, you will be able to choose a GID of whose users will
be unable to connect to other hosts from your machine, but will be
able to run servers.  If this option is enabled, all users in the group
you specify will have to use passive mode when initiating ftp transfers
from the shell on your machine.  If the sysctl option is enabled, a
sysctl option with name "socket_client" is created.

GID to deny client sockets for

GRKERNSEC_SOCKET_CLIENT_GID\

Here you can choose the GID to disable client socket access for.
Remember to add the users you want client socket access disabled for to
the GID specified here.  If the sysctl option is enabled, a sysctl
option with name "socket_client_gid" is created.

Deny server sockets to group

GRKERNSEC_SOCKET_SERVER\
Related sysctl variables:\
:kernel.grsecurity.socket_server: kernel.grsecurity.socket_server_gid

If you say Y here, you will be able to choose a GID of whose users will
be unable to run server applications from your machine.  If the sysctl
option is enabled, a sysctl option with name "socket_server" is created.

GID to deny server sockets for

GRKERNSEC_SOCKET_SERVER_GID\

Here you can choose the GID to disable server socket access for.
Remember to add the users you want server socket access disabled for to
the GID specified here.  If the sysctl option is enabled, a sysctl
option with name "socket_server_gid" is created.

Physical Protections

Deny new USB connections after toggle

GRKERNSEC_DENYUSB\

If you say Y here, a new sysctl option with name "deny_new_usb"
will be created.  Setting its value to 1 will prevent any new
USB devices from being recognized by the OS.  Any attempted USB
device insertion will be logged.  This option is intended to be
used against custom USB devices designed to exploit vulnerabilities
in various USB device drivers.

For greatest effectiveness, this sysctl should be set after any
relevant init scripts.  This option is safe to enable in distros
as each user can choose whether or not to toggle the sysctl.

Reject all USB devices not connected at boot

GRKERNSEC_DENYUSB_FORCE\

If you say Y here, a variant of GRKERNSEC_DENYUSB will be enabled
that doesn't involve a sysctl entry.  This option should only be
enabled if you're sure you want to deny all new USB connections
at runtime and don't want to modify init scripts.  This should not
be enabled by distros.  It forces the core USB code to be built
into the kernel image so that all devices connected at boot time
can be recognized and new USB device connections can be prevented
prior to init running.

Sysctl Support

Sysctl support

GRKERNSEC_SYSCTL\

If you say Y here, you will be able to change the options that
grsecurity runs with at bootup, without having to recompile your
kernel.  You can echo values to files in /proc/sys/kernel/grsecurity
to enable (1) or disable (0) various features.  All the sysctl entries
are mutable until the "grsec_lock" entry is set to a non-zero value.
All features enabled in the kernel configuration are disabled at boot
if you do not say Y to the "Turn on features by default" option.
All options should be set at startup, and the grsec_lock entry should
be set to a non-zero value after all the options are set.
*THIS IS EXTREMELY IMPORTANT*

Extra sysctl support for distro makers (READ HELP)

GRKERNSEC_SYSCTL_DISTRO\

If you say Y here, additional sysctl options will be created
for features that affect processes running as root.  Therefore,
it is critical when using this option that the grsec_lock entry be
enabled after boot.  Only distros with prebuilt kernel packages
with this option enabled that can ensure grsec_lock is enabled
after boot should use this option.
*Failure to set grsec_lock after boot makes all grsec features
this option covers useless*

Currently this option creates the following sysctl entries:
"Disable Privileged I/O": "disable_priv_io"

Turn on features by default

GRKERNSEC_SYSCTL_ON\

If you say Y here, instead of having all features enabled in the
kernel configuration disabled at boot time, the features will be
enabled at boot time.  It is recommended you say Y here unless
there is some reason you would want all sysctl-tunable features to
be disabled by default.  As mentioned elsewhere, it is important
to enable the grsec_lock entry once you have finished modifying
the sysctl entries.

Logging Options

Seconds in between log messages (minimum)

GRKERNSEC_FLOODTIME\

This option allows you to enforce the number of seconds between
grsecurity log messages.  The default should be suitable for most
people, however, if you choose to change it, choose a value small enough
to allow informative logs to be produced, but large enough to
prevent flooding.

Setting both this value and GRKERNSEC_FLOODBURST to 0 will disable
any rate limiting on grsecurity log messages.

Number of messages in a burst (maximum)

GRKERNSEC_FLOODBURST\

This option allows you to choose the maximum number of messages allowed
within the flood time interval you chose in a separate option.  The
default should be suitable for most people, however if you find that
many of your logs are being interpreted as flooding, you may want to
raise this value.

Setting both this value and GRKERNSEC_FLOODTIME to 0 will disable
any rate limiting on grsecurity log messages.