Grsecurity/Appendix/Sysctl Options

These tables describe every available option in grsecurity that can be changed at runtime. They are changed using the sysctl interface, or by echoing values to files in /proc/sys/kernel/grsecurity/. The available options vary depending on how grsecurity was configured. See Configuring and Installing grsecurity and Runtime configuration for more information.

To find out what options are available in your system, list the contents of /proc/sys/kernel/grsecurity. If you use the sysctl interface, all of grsecurity's option are prefixed with kernel.grsecurity (e.g. kernel.grsecurity.audit_chdir).

Auditing/logging

Option	Description
audit_chdir	Log all chdir() calls. WARNING: This option when enabled may produce a lot of logs.
audit_group	Specifies a single group (GID) for auditing. The exec, chdir, (un)mount and ipc logging features will only operate on this group.
audit_mount	Log all mounts and unmounts.
audit_textrel	Log text relocations 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. WARNING: Only Linux distribution developers should enable this option, 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.
chroot_execlog	Log all executions inside a chroot jail to syslog. This can cause a large amount of logs if certain applications (e.g. djb's daemontools) are installed on the system.
exec_logging	Log all execve() calls (since the other exec*() calls are frontends to execve(), all execution will be logged). WARNING: This option when enabled will produce a LOT of logs, especially on an active system.
forkfail_logging	Log all failed fork() attempts. This could suggest a fork bomb, or someone attempting to overstep their process limit.
resource_logging	Log all attempts to overstep resource limits with the resource name, the requested size, and the current limit. If the RBAC system is enabled the sysctl value is ignored.
signal_logging	Log certain important signals, such as SIGSEGV, 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.
timechange_logging	Log any changes of the system clock.

Chroot restrictions

Option	Description
chroot_caps	If enabled, 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.
chroot_deny_chmod	If enabled, 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.
chroot_deny_chroot	If enabled, 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.
chroot_deny_fchdir	If enabled, 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.
chroot_deny_mknod	If enabled, 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 enable this option, unless you run into software incompatibilities.
chroot_deny_mount	If enabled, processes inside a chroot will not be able to mount or remount filesystems.
chroot_deny_pivot	If enabled, 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.
chroot_deny_shmat	If enabled, 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 enable this option.
chroot_deny_sysctl	If enabled, 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 enable this option.
chroot_deny_unix	If enabled, 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 enable this option.
chroot_enforce_chdir	If enabled, 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 enable this option, since it's not known to break any software.
chroot_findtask	If enabled, 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.
chroot_restrict_nice	If enabled, 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.

Network-based features

Option	Description
socket_all	If enabled, the option "socket_all_gid" specifies a GID of whose users will be unable to connect to other hosts from your machine or run server applications from your machine.
socket_all_gid	The GID to disable socket access for. Remember to add the users you want socket access disabled for to the GID specified here.
socket_client	If enabled, the option "socket_client_gid" specifies 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.
socket_client_gid	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.
socket_server	If enabled, the option "socket_server_gid" specifies a GID of whose users will be unable to run server applications from your machine.
socket_server_gid	The GID to disable socket access for. Remember to add the users you want server socket access disabled for to the GID specified here.
ip_blackhole	If enabled, the option "ip_blackhole" turns on the TCP/UDP blackhole feature, preventing RST or ICMP packets from being sent in response to packets sent to ports not being listened on.

Miscellaneous options

Option	Description
disable_modules	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. 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.
dmesg	If enabled, 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.
execve_limiting	If enabled, 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.
fifo_restrictions	If enabled, 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.
grsec_lock	All the sysctl entries are mutable until this option is set to a non-zero value. All options should be set at startup, and this option should be set to a non-zero value after all the options are set. THIS IS EXTREMELY IMPORTANT.
harden_ptrace	If enabled, 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 strace ./binary and gdb ./binary will still work, but attaching to arbitrary processes will not.
linking_restrictions	If enabled, /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. User will also not be able to hardlink to files they do not own.
romount_protect	If enabled, 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.
tpe	Enforce Trusted Patch Execution (TPE). A trusted path/directory is one that is owned by root and writable only by root. See also option "tpe_gid".
tpe_invert	If enabled, 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. Unlike other sysctl options, this entry will default to on for backward-compatibility.
tpe_gid	If you have selected the "Invert GID option", setting this GID determines what group TPE restrictions will be disabled for. If you have not selected the "Invert GID option", setting this GID determines what group TPE restrictions will be enabled for.
tpe_restrict_all	If enabled, 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.