Grsecurity/Appendix/Grsecurity and PaX Configuration Options

Introduction

This is a list of all grsecurity and PaX configuration options in the kernel. You can access this same information using the kernel

configuration's built-in help. This page contains only the configuration options present in the latest stable grsecurity release.

In the 2.6 kernels, the grsecurity options are under Security options » Grsecurity. In the 2.4 kernels there is a top-level menu item called Grsecurity.

Please note that this listing is out of date. The most up to date information is available in the kernel configuration help. Please edit this page to reflect the current configuration help information if you'd like to assist.

Grsecurity Kernel Configuration Options

Configuration option: CONFIG_GRKERNSEC

Security Level

Configuration option: CONFIG_GRKERNSEC_LOW | CONFIG_GRKERNSEC_MEDIUM | CONFIG_GRKERNSEC_HIGH | CONFIG_GRKERNSEC_CUSTOM
This menu lets you choose between four security levels

Low

If you choose this option, several of the grsecurity options will be enabled that will give you greater protection against a number of attacks, while assuring that none of your software will have any conflicts with the additional security measures. If you run a lot of unusual software, or you are having problems with the higher security levels, you should say Y here. With this option, the following features are enabled:

• Linking restrictions
• FIFO restrictions
• Enforcing RLMIT_NPROC on execve()
• Restricted dmesg
• Enforced chdir("/") on chroot
• Runtime module disabling

Medium

If you say Y here, several features in addition to those included in the low additional security level will be enabled. These features provide even more security to your system, though in rare cases they may be incompatible with very old or poorly written software. If you enable this option, make sure that your auth service (identd) is running as gid 1001. With this option the following features (in addition to those provided in the low additional security level) will be enabled:

• Failed fork logging
• Time change logging
• Signal logging
• Deny mounts in chroot
• Deny double chrooting
• Deny sysctl writes in chroot
• Deny mknod in chroot
• Deny access to abstract AF_UNIX sockets out of chroot
• Deny pivot_root in chroot
• Denied writes of /dev/kmem, /dev/mem, and /dev/port
• /proc restrictions with special GID set to 10 (usually wheel)
• Address Space Layout Randimization (ASLR)
• Prevent exploitation of most refcount overflows
• Bounds checking of copying between the kernel and userland

High

If you say Y here, many of the features of grsecurity will be enabled, that will protect you against many kinds of attacks against your system. The heightened security comes at a cost of an increased chance of incompatibilities with rare software on your machine. Since this security level enables PaX, you should view <http://pax.grsecurity.net> and read about the PaX project. While you are there, download chpax and run it on binaries that cause problems with PaX. Also remember that since the /proc restrictions are enabled, you must run your identd as gid 1001. This security level enables the following features in addition to those listed in the low and medium security levels:

• Additional /proc restrictions
• Chmod restrictions in chroot
• No signals, ptrace, or viewing or processes outside of chroot
• Capability restrictions in chroot
• Deny fchdir out of chroot
• Priority restrictions in chroot
• Segmentation-based implementation of PaX
• Mprotect restrictions
• Removal of addresses from /proc/<pid>/[smaps|maps|stat]
• Kernel stack randomization
• Mount/unmount/remount logging
• Kernel symbol hiding
• Preventation of memory exhaustion based exploits
• Hardening of module auto-loading
• Ptrace restrictions
• Restricted vm86 mode
• Restricted sysfs/debugfs
• Active kernel exploit response

Custom

If you say Y here, you will be able to configure every grsecurity option, which allows you to enable many more features that aren't covered in the basic security levels. These additional features include TPE, socket restrictions, and the sysctl system for grsecurity. It is advised that you read through the help for each option to determine its usefulness in your situation.

Address Space Protection

This menu lets you choose options that affect the Address Space Protection

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

Configuration option: CONFIG_GRKERNSEC_KMEM
If you say Y here, /dev/kmem and /dev/mem< won't be allowed to be written to via mmap or otherwise to modify the running kernel. /dev/port will also not be allowed to be opened. If you have module support disabled, enabling this will close up four ways that are currently used to insert malicious code into the running kernel. Even with all these features enable, we still highly recommend that you use the RBAC system, as it is still possible for an attacker to modify the running kernel through privileged I/O granted by ioperm/iopl. If you are not using XFree86, you may be able to stop this additional case by enabling the "Disable privileged I/O" option. Though nothing legitimately writes to /dev/kmem, XFree86 does need to write to /dev/mem but only to video memory, which is the only writing we allow in this case. If /dev/kmem or /dev/mem are mmaped without PROT_WRITE, they will not be allowed to mprotect it with PROT_WRITE later. It is highly recommended that you say Y here if you meet all the conditions above.

Disable privileged I/O

Configuration option: CONFIG_GRKERNSEC_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 CONFIG_RTC is enabled if this option is enabled, to ensure that hwclock operated correctly. XFree86 still will not operate correctly with this option enabled, so DO NOT CHOOSE Y IF YOU USE XFree86. If you use XFree86 and you still want to protect the kernel against modification, use the RBAC system.

Remove addresses from /proc/<pid>/[smaps|maps|stat]

Configuration option: CONFIG_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. If you use PaX it is greatly recommended that you say Y here as it closes up a hole that makes the full ALSR useless for suid binaries.

Deter exploit bruteforcing

Configuration option: CONFIG_GRKERNSEC_BRUTE
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 crashed 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 processes terminated, and they are prevented from executing any further processes 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

Configuration option: CONFIG_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 time 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 users logging in will cause the ecb(aes), ecb(aes)-all, cbc(aes), and cbc(aes)-all modules to be loaded.

Runtime module disabling

Configuration option: CONFIG_GRKERNSEC_??? (is this option deprecated?)
If you say Y here, you will be able to disable the ability to (un)load modules at runtime. This feature is useful if you need the ability to load kernel modules at boot time, but do not want to allow an attacker to load a rootkit kernel module into the system, or remove a loaded kernel module important to system functioning. You should enable the /dev/mem protection feature as well, since rootkits can be inserted into the kernel via other methods than kernel modules. Since an untrusted module could still be loaded by modifying init scripts and rebooting the system, it is also recommended that you enable the RBAC system. If you enable this option, a sysctl option with name "disable_modules" will be created. Setting this option to "1" disables module loading. After this option is set, no further writes to it are allowed until the system is rebooted.

Hide kernel symbols

Configuration option: CONFIG_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 to provide a useful protection against local and remote kernel exploitation of overflows and arbitrary read/write vulnerabilities.

Active kernel exploit response

Configuration option: CONFIG_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.

Role Based Access Control Options

This menu lets you choose options that affect the RBAC system

Disable RBAC system

Configuration option: CONFIG_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

Configuration option: CONFIG_GRKERNSEC_NO_RBAC
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

Configuration option: CONFIG_GRKERNSEC_ACL_MAXTRIES
This options 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

Configuration option: CONFIG_GRKERNSEC_ACL_TIMEOUT
This options specified 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

This menu lets you choose options that affect filesystem security

Proc restrictions

Configuration option: CONFIG_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 as a non-root user, you will have to run it was the group you specify here.

Restrict /proc to user only

Configuration option: CONFIG_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

Configuration option: CONFIG_GRKERNSEC_PROC_USERGROUP
If you say Y here you will be able to select a group that will be able to view all processes, network-related information, and kernel and symbol information. This option is useful if you want to run identd as a non-root user.

• GID for special group (CONFIG_GRKERNSEC_PROC_GID) - Specifies the group id of the special group

Additional restrictions

Configuration option: CONFIG_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

Configuration option: CONFIG_GRKERNSEC_LINK
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 (i.e. /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.

FIFO restrictions

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

Sysfs/debugfs restriction

Configuration option: CONFIG_GRKERNSEC_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 only be accessible 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.

This option is equivalent to a chmod 0700 of the mount paths.

Runtime read-only mount protection

Configuration option: CONFIG_GRKERNSEC_ROFS
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. This feature is mainly intended for secure embedded systems.

Chroot jail restrictions

Configuration option: CONFIG_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.

Deny mounts

Configuration option: CONFIG_GRKERNSEC_CHROOT_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

Configuration option: CONFIG_GRKERNSEC_CHROOT_DOUBLE
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

Configuration option: CONFIG_GRKERNSEC_CHROOT_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 there should not be allowed. If the sysctl option is enabled, a sysctl option with name chroot_deny_pivot is created.

Enforce chdir("/") on all chroots

Configuration option: CONFIG_GRKERNSEC_CHROOT_CHDIR
If you say Y here, the current working directory of all newly-chrooted applications will be set to 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

Configuration option: CONFIG_GRKERNSEC_CHROOT_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 out of chroot

Configuration option: CONFIG_GRKERNSEC_CHROOT_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. If the sysctl option is enabled, a sysctl option with name chroot_deny_fchdir is created.

Deny mknod

Configuration option: CONFIG_GRKERNSEC_CHROOT_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

Configuration option: CONFIG_GRKERNSEC_CHROOT_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

Configuration option: CONFIG_GRKERNSEC_CHROOT_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

Configuration option: CONFIG_GRKERNSEC_CHROOT_FINDTASK
If you say Y here, processes inside a chroot will not be able to kill, send signals with fcntl, ptrace, capget, getpgid, 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

Configuration option: CONFIG_GRKERNSEC_CHROOT_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

Configuration option: CONFIG_GRKERNSEC_CHROOT_SYSCTL
If you say Y here, an attacker in a chroot will not be able to write 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.

Capability restrictions

Configuration option: CONFIG_GRKERNSEC_CHROOT_CAPS
If you say Y here, the capabilities on all root 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.

Kernel auditing

This menu lets you choose options that affect the kernel auditing

Single group for auditing

Configuration option: CONFIG_GRKERNSEC_AUDIT_GROUP
If you say Y here, the exec, chdir, (un)mount and ipc logging features will only operate on a group you specify. This options 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 (CONFIG_GRKERNSEC_AUDIT_GID) - The id of the group being audited

Exec logging

Configuration option: CONFIG_GRKERNSEC_EXECLOG
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

Configuration option: CONFIG_GRKERNSEC_RESLOG
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

Configuration option: CONFIG_GRKERNSEC_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 (e.g. 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

Configuration option: CONFIG_GRKERNSEC_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

Configuration option: CONFIG_GRKERNSEC_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

Configuration option: CONFIG_GRKERNSEC_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.

Signal logging

Configuration option: CONFIG_GRKERNSEC_SIGNAL
If you say Y here, certain important signals will be logged, such as SIGSEV, which will as a result inform you of when an 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

Configuration option: CONFIG_GRKERNSEC_FORKFAIL
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

Configuration option: CONFIG_GRKERNSEC_TIME
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/<pid>/ipaddr support

Configuration option: CONFIG_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

Configuration option: CONFIG_GRKERNSEC_RWXMAP_LOG
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. If the sysctl option is enabled, a sysctl option with name rwxmap_logging is created.

ELF text relocations logging (READ HELP)

Configuration option: CONFIG_GRKERNSEC_AUDIT_TEXTREL
If you say Y here, text relocations will be logged with the filename of the offending library or binary. The purpose of the feature is to help Linux distribution developers get rid of libraries and binaries that need text relocations which hinder the future progress of PaX. Only Linux distribution developers should say Y here, and never on a production machine, as this option creates an information leak that could aid an attacker in defeating the randomization of a single memory region. If the sysctl option is enabled, a sysctl option with name audit_textrel is created.

Executable Protections

This menu lets you choose options that affect executable protections

Enforce RLMIT_NPROC on execs

Configuration option: CONFIG_GRKERNSEC_??? (is this option deprecated?)
If you say Y here, users with a resource limit on processes will have the value checked during execve() calls. The current system only checks the system limit during fork() calls. If the sysctl option is enabled, a sysctl option with name execve_limiting is created.

Dmesg(8) restriction

Configuration option: CONFIG_GRKERNSEC_DMESG
If you say Y here, non-root users will not be able to use dmesg(8) to view up to the last 4kb of messages in the kernel's log buffer. If the sysctl option is enabled, a sysctl option with name dmesg is created.

Deter ptrace-based process snooping

Configuration option: CONFIG_GRKERNSEC_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.

Trusted Path Execution (TPE)

Configuration option: CONFIG_GRKERNSEC_TPE
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 non-root users

Configuration option: CONFIG_GRKERNSEC_TPE_ALL
If you say Y here, all non-root users other than the ones in the group specified in the main TPE option 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 options

Configuration option: CONFIG_GRKERNSEC_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 no for backward-compatibility.

• GID for trusted/untrusted users (CONFIG_GRKERNSEC_TPE_GID) - If you have selected the "Invert GID option" above, setting this GID determines what group TPE restrictions will be ==disabled== for. If you have not selected the "Invert GID option" above, 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.

Network Protections

This menu lets you choose options that affect network protections

Larger entropy pools

Configuration option: CONFIG_GRKERNSEC_RANDNET
If you say Y here, the entropy pools used for many features of Linux and grsecurity will be doubled in size. Since several grsecurity features use additional randomness, it is recommended that you say Y here. Saying Y here has a similar effect as modifying /proc/sys/kernel/random/poolsize.

TCP/UDP blackhole

Configuration option: CONFIG_GRKERNSEC_BLACKHOLE
If you say Y here, neither TCP nor ICMP destination-unreachable packets will be sent in response to packets sent to ports for which no associated listening process exists. 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.

Socket restrictions

Configuration option: CONFIG_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

Configuration option: CONFIG_GRKERNSEC_SOCKET_ALL
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 (CONFIG_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

Configuration option: CONFIG_GRKERNSEC_SOCKET_CLIENT
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 (CONFIG_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

Configuration option: CONFIG_GRKERNSEC_SOCKET_SERVER
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 (CONFIG_GRKERNSEC_SOCKET_SERVER_GID) - Here you can choose the GID to disable 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.

Sysctl support

This menu lets you choose whether to enable or disable the sysctl support of grsecurity

Sysctl support

Configuration option: CONFIG_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

Configuration option: CONFIG_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

Configuration option: CONFIG_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

This menu lets you choose logging options

Seconds in between log messages (minimum)

Configuration option: CONFIG_GRKERNSEC_FLOODTIME
This options 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.

Number of messages in a burst (maximum)

Configuration option: CONFIG_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.

PaX Kernel Configuration Options

Configuration option: CONFIG_PAX

PaX Control

This menu lets you choose core PaX features

Support soft mode

Configuration option: CONFIG_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 support as it is the only way to mark executables for soft mode use. Soft mode can be activated by using the "pax_softmode=1" kernel command line option on boot. Furthermore you can control various PaX features at runtime via the entries in /proc/sys/kernel/pax.

Use legacy ELF header marking

Configuration option: CONFIG_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.

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

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

Use ELF program header marking

Configuration option: CONFIG_PAX_PT_PAX_FLAGS
Enabling this option will alllow 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 [1]).

If you have applications not marked by the PT_PAX_FLAGS ELF program header then you MUST enable the EI_PAX marking support. Othwerwise they will not get any protection.

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

MAC system integration

Configuration option: CONFIG_PAX_NO_ACL_FLAGS | CONFIG_PAX_HAVE_ACL_FLAGS | CONFIG_PAX_HOOK_ACL_FLAGS
Mandatory Access Control systems have the option of controlling PaX flags on a per executable basis, choose the method supported by your particular system.

• none: if your MAC system does not interact with PaX,
• direct: if your MAC system defines pax_set_flags() itself,
• hook: if your MAC system uses the pax_set_flags_func callback.
  
  

NOTE: this option is for developers/integrators only

Non-executable pages

This menu lets you choose PaX settings that enforce non-executable memory pages

Enforce non-executable pages

Configuration option: CONFIG_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 heap) and then execute it.

If the attacked program was running with different (typically higher) privileges 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.).

Paging based non-executable pages

Configuration option: CONFIG_PAX_PAGEEXEC
This implementation is based on the paging feature of the CPU. On i386 without hardware non-executable bit support there is a variable but usually low performance impact, however on Intel's P4 core based CPUs it is very high so you should not enable this for kernels meant to be used on such CPUs.

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

Note that several architectures require various emulations due to badly designed userland ABIs, this will cause a performance impact but will disappear as soon as userland is fixed (e.g., ppc users can make use of the secure-plt feature found in binutils).

Segmentation based non-executable pages

Configuration option: CONFIG_PAX_SEGMEXEC (is this option deprecated?)
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

Configuration option: CONFIG_PAX_EMUTRAMP
There are some programs and libraries that for one reason or another attempt to execute special small code snippets from the non-executable pages. Most notably 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 thr chpax or paxctl utilities to enable trampoline emulation for the affected programs yet still have the protection provided by the non-executable pages.

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

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

Restrict mprotect()

Configuration option: CONFIG_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

Configuration option: CONFIG_PAX_MPROTECT_COMPAT
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.

Allow ELF text relocations

Configuration option: CONFIG_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.

Enforce non-executable kernel pages

Configuration option: CONFIG_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.

Address Space Layout Randomization

This menu lets you choose features that affect the ASLR

Address Space Layout Randomization

Configuration option: CONFIG_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 allow the kernel to detect such attempts and react on them. PaX itself provides no reaction mechanism, instead it is strongly encouraged that you make use of Nergal's segvguard (ftp://ftp.pl.openwall.com/misc/segvguard/) or grsecurity's (http://grsecurity.net/) built-int 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 if 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

Configuration option: CONFIG_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 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 base

Configuration option: CONFIG_PAX_RANDUSTACK
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 chapx or paxctl on a per file basis.

Randomize mmap() base

Configuration option: CONFIG_PAX_RANDMMAP
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 fill 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://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

This menu lets you choose miscellaneous hardening features of PaX

Sanitize all freed memory

Configuration option: CONFIG_PAX_MEMORY_SANITIZE
By saying Y here the kernel will erase memory pages as soon as they are freed. This is turn reduces the lifetime of data stored in the pages, making it less likely that sensitive information such as passwords, cryptographic secrets, etc. stay in memory for too long.

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

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

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

Sanitize all freed memory

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

Prevent invalid userland pointer dereferences

Configuration option: CONFIG_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.

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

Prevent various kernel object reference counter overflows

Configuration option: CONFIG_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 and overflowed refcount will never be freed and therefore will leak memory. Note that this leak also happends 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 heap object copies between kernel and userland

Configuration option: CONFIG_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 checks for the SLUB allocator.