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