# # grecurity configuration # menu "Memory Protections" depends on GRKERNSEC config GRKERNSEC_KMEM bool "Deny reading/writing to /dev/kmem, /dev/mem, and /dev/port" default y if GRKERNSEC_CONFIG_AUTO select STRICT_DEVMEM if (X86 || ARM || TILE || S390) help 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. config GRKERNSEC_VM86 bool "Restrict VM86 mode" default y if (GRKERNSEC_CONFIG_AUTO && GRKERNSEC_CONFIG_SERVER) depends on X86_32 help 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. config GRKERNSEC_IO bool "Disable privileged I/O" default y if (GRKERNSEC_CONFIG_AUTO && GRKERNSEC_CONFIG_SERVER) depends on X86 select RTC_CLASS select RTC_INTF_DEV select RTC_DRV_CMOS help 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. config GRKERNSEC_BPF_HARDEN bool "Harden BPF interpreter" default y if GRKERNSEC_CONFIG_AUTO help Unlike previous versions of grsecurity that hardened both the BPF interpreted code against corruption at rest as well as the JIT code against JIT-spray attacks and attacker-controlled immediate values for ROP, this feature will enforce disabling of the new eBPF JIT engine and will ensure the interpreted code is read-only at rest. This feature may be removed at a later time when eBPF stabilizes to entirely revert back to the more secure pre-3.16 BPF interpreter/JIT. If you're using KERNEXEC, it's recommended that you enable this option to supplement the hardening of the kernel. config GRKERNSEC_PERF_HARDEN bool "Disable unprivileged PERF_EVENTS usage by default" default y if GRKERNSEC_CONFIG_AUTO depends on PERF_EVENTS help 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. config GRKERNSEC_RAND_THREADSTACK bool "Insert random gaps between thread stacks" default y if GRKERNSEC_CONFIG_AUTO depends on PAX_RANDMMAP && !PPC help 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. config GRKERNSEC_PROC_MEMMAP bool "Harden ASLR against information leaks and entropy reduction" default y if (GRKERNSEC_CONFIG_AUTO || PAX_NOEXEC || PAX_ASLR) depends on PAX_NOEXEC || PAX_ASLR help If you say Y here, the /proc//maps and /proc//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/ 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. config GRKERNSEC_KSTACKOVERFLOW bool "Prevent kernel stack overflows" default y if GRKERNSEC_CONFIG_AUTO depends on X86_64 help 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. config GRKERNSEC_BRUTE bool "Deter exploit bruteforcing" default y if GRKERNSEC_CONFIG_AUTO help 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. config GRKERNSEC_MODHARDEN bool "Harden module auto-loading" default y if GRKERNSEC_CONFIG_AUTO depends on MODULES help 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. config GRKERNSEC_HIDESYM bool "Hide kernel symbols" default y if GRKERNSEC_CONFIG_AUTO select PAX_USERCOPY help 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. config GRKERNSEC_RANDSTRUCT bool "Randomize layout of sensitive kernel structures" default y if GRKERNSEC_CONFIG_AUTO depends on GCC_PLUGINS select GRKERNSEC_HIDESYM select MODVERSIONS if MODULES help 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 tools/gcc/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. config GRKERNSEC_RANDSTRUCT_PERFORMANCE bool "Use cacheline-aware structure randomization" depends on GRKERNSEC_RANDSTRUCT default y if GRKERNSEC_CONFIG_PRIORITY_PERF help If you say Y here, the RANDSTRUCT randomization will make a best effort at restricting randomization to cacheline-sized groups of elements. It will further not randomize bitfields in structures. This reduces the performance hit of RANDSTRUCT at the cost of weakened randomization. config GRKERNSEC_KERN_LOCKOUT bool "Active kernel exploit response" default y if GRKERNSEC_CONFIG_AUTO depends on X86 || ARM || PPC || SPARC help 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. config GRKERNSEC_OLD_ARM_USERLAND bool "Old ARM userland compatibility" depends on ARM && (CPU_V6 || CPU_V6K || CPU_V7) help 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). endmenu menu "Role Based Access Control Options" depends on GRKERNSEC config GRKERNSEC_RBAC_DEBUG bool config GRKERNSEC_NO_RBAC bool "Disable RBAC system" help 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. config GRKERNSEC_ACL_HIDEKERN bool "Hide kernel processes" help If you say Y here, all kernel threads will be hidden to all processes but those whose subject has the "view hidden processes" flag. config GRKERNSEC_ACL_MAXTRIES int "Maximum tries before password lockout" default 3 help 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. config GRKERNSEC_ACL_TIMEOUT int "Time to wait after max password tries, in seconds" default 30 help 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. endmenu menu "Filesystem Protections" depends on GRKERNSEC config GRKERNSEC_PROC bool "Proc restrictions" default y if GRKERNSEC_CONFIG_AUTO help 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. config GRKERNSEC_PROC_USER bool "Restrict /proc to user only" depends on GRKERNSEC_PROC help 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. config GRKERNSEC_PROC_USERGROUP bool "Allow special group" default y if GRKERNSEC_CONFIG_AUTO depends on GRKERNSEC_PROC && !GRKERNSEC_PROC_USER help 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. config GRKERNSEC_PROC_GID int "GID for special group" depends on GRKERNSEC_PROC_USERGROUP default 1001 config GRKERNSEC_PROC_ADD bool "Additional restrictions" default y if GRKERNSEC_CONFIG_AUTO depends on GRKERNSEC_PROC_USER || GRKERNSEC_PROC_USERGROUP help 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. config GRKERNSEC_LINK bool "Linking restrictions" default y if GRKERNSEC_CONFIG_AUTO help 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. config GRKERNSEC_SYMLINKOWN bool "Kernel-enforced SymlinksIfOwnerMatch" default y if GRKERNSEC_CONFIG_AUTO && GRKERNSEC_CONFIG_SERVER help 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. config GRKERNSEC_SYMLINKOWN_GID int "GID for users with kernel-enforced SymlinksIfOwnerMatch" depends on GRKERNSEC_SYMLINKOWN default 1006 help Setting this GID determines what group kernel-enforced SymlinksIfOwnerMatch will be enabled for. If the sysctl option is enabled, a sysctl option with name "symlinkown_gid" is created. config GRKERNSEC_FIFO bool "FIFO restrictions" default y if GRKERNSEC_CONFIG_AUTO help 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. config GRKERNSEC_SYSFS_RESTRICT bool "Sysfs/debugfs restriction" default y if (GRKERNSEC_CONFIG_AUTO && GRKERNSEC_CONFIG_SERVER) depends on SYSFS help 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 config GRKERNSEC_ROFS bool "Runtime read-only mount protection" depends on SYSCTL help 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. config GRKERNSEC_DEVICE_SIDECHANNEL bool "Eliminate stat/notify-based device sidechannels" default y if GRKERNSEC_CONFIG_AUTO help 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. config GRKERNSEC_CHROOT bool "Chroot jail restrictions" default y if GRKERNSEC_CONFIG_AUTO help 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. config GRKERNSEC_CHROOT_MOUNT bool "Deny mounts" default y if GRKERNSEC_CONFIG_AUTO depends on GRKERNSEC_CHROOT help 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. config GRKERNSEC_CHROOT_DOUBLE bool "Deny double-chroots" default y if GRKERNSEC_CONFIG_AUTO depends on GRKERNSEC_CHROOT help 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. config GRKERNSEC_CHROOT_PIVOT bool "Deny pivot_root in chroot" default y if GRKERNSEC_CONFIG_AUTO depends on GRKERNSEC_CHROOT help 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. config GRKERNSEC_CHROOT_CHDIR bool "Enforce chdir(\"/\") on all chroots" default y if GRKERNSEC_CONFIG_AUTO depends on GRKERNSEC_CHROOT help 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. config GRKERNSEC_CHROOT_CHMOD bool "Deny (f)chmod +s" default y if GRKERNSEC_CONFIG_AUTO depends on GRKERNSEC_CHROOT help 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. config GRKERNSEC_CHROOT_FCHDIR bool "Deny fchdir and fhandle out of chroot" default y if GRKERNSEC_CONFIG_AUTO depends on GRKERNSEC_CHROOT help 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. config GRKERNSEC_CHROOT_MKNOD bool "Deny mknod" default y if GRKERNSEC_CONFIG_AUTO depends on GRKERNSEC_CHROOT help 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. config GRKERNSEC_CHROOT_SHMAT bool "Deny shmat() out of chroot" default y if GRKERNSEC_CONFIG_AUTO depends on GRKERNSEC_CHROOT help 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. config GRKERNSEC_CHROOT_UNIX bool "Deny access to abstract AF_UNIX sockets out of chroot" default y if GRKERNSEC_CONFIG_AUTO depends on GRKERNSEC_CHROOT help 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. config GRKERNSEC_CHROOT_FINDTASK bool "Protect outside processes" default y if GRKERNSEC_CONFIG_AUTO depends on GRKERNSEC_CHROOT help 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. config GRKERNSEC_CHROOT_NICE bool "Restrict priority changes" default y if GRKERNSEC_CONFIG_AUTO depends on GRKERNSEC_CHROOT help 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. config GRKERNSEC_CHROOT_SYSCTL bool "Deny sysctl writes" default y if GRKERNSEC_CONFIG_AUTO depends on GRKERNSEC_CHROOT help 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. config GRKERNSEC_CHROOT_RENAME bool "Deny bad renames" default y if GRKERNSEC_CONFIG_AUTO depends on GRKERNSEC_CHROOT help 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. config GRKERNSEC_CHROOT_CAPS bool "Capability restrictions" default y if GRKERNSEC_CONFIG_AUTO depends on GRKERNSEC_CHROOT help 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. config GRKERNSEC_CHROOT_INITRD bool "Exempt initrd tasks from restrictions" default y if GRKERNSEC_CONFIG_AUTO depends on GRKERNSEC_CHROOT && BLK_DEV_INITRD help 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. endmenu menu "Kernel Auditing" depends on GRKERNSEC config GRKERNSEC_AUDIT_GROUP bool "Single group for auditing" help 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. config GRKERNSEC_AUDIT_GID int "GID for auditing" depends on GRKERNSEC_AUDIT_GROUP default 1007 config GRKERNSEC_EXECLOG bool "Exec logging" help 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. config GRKERNSEC_RESLOG bool "Resource logging" default y if GRKERNSEC_CONFIG_AUTO help 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. config GRKERNSEC_CHROOT_EXECLOG bool "Log execs within chroot" help 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. config GRKERNSEC_AUDIT_PTRACE bool "Ptrace logging" help 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. config GRKERNSEC_AUDIT_CHDIR bool "Chdir logging" help 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. config GRKERNSEC_AUDIT_MOUNT bool "(Un)Mount logging" help 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. config GRKERNSEC_SIGNAL bool "Signal logging" default y if GRKERNSEC_CONFIG_AUTO help 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. config GRKERNSEC_FORKFAIL bool "Fork failure logging" help 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. config GRKERNSEC_TIME bool "Time change logging" default y if GRKERNSEC_CONFIG_AUTO help 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. config GRKERNSEC_PROC_IPADDR bool "/proc//ipaddr support" default y if GRKERNSEC_CONFIG_AUTO help If you say Y here, a new entry will be added to each /proc/ 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. config GRKERNSEC_RWXMAP_LOG bool 'Denied RWX mmap/mprotect logging' default y if GRKERNSEC_CONFIG_AUTO depends on PAX_MPROTECT && !PAX_EMUPLT && !PAX_EMUSIGRT help 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. endmenu menu "Executable Protections" depends on GRKERNSEC config GRKERNSEC_DMESG bool "Dmesg(8) restriction" default y if GRKERNSEC_CONFIG_AUTO help 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. config GRKERNSEC_HARDEN_PTRACE bool "Deter ptrace-based process snooping" default y if GRKERNSEC_CONFIG_AUTO help 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. config GRKERNSEC_PTRACE_READEXEC bool "Require read access to ptrace sensitive binaries" default y if GRKERNSEC_CONFIG_AUTO help 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. config GRKERNSEC_SETXID bool "Enforce consistent multithreaded privileges" default y if GRKERNSEC_CONFIG_AUTO depends on (X86 || SPARC64 || PPC || ARM || MIPS) help 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. config GRKERNSEC_HARDEN_IPC bool "Disallow access to overly-permissive IPC objects" default y if GRKERNSEC_CONFIG_AUTO depends on SYSVIPC help 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. config GRKERNSEC_HARDEN_TTY bool "Disallow unprivileged use of command injection" default y if GRKERNSEC_CONFIG_AUTO help 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. config GRKERNSEC_TPE bool "Trusted Path Execution (TPE)" default y if GRKERNSEC_CONFIG_AUTO && GRKERNSEC_CONFIG_SERVER help 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. config GRKERNSEC_TPE_ALL bool "Partially restrict all non-root users" depends on GRKERNSEC_TPE help 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. config GRKERNSEC_TPE_INVERT bool "Invert GID option" depends on GRKERNSEC_TPE help 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. config GRKERNSEC_TPE_GID int default GRKERNSEC_TPE_UNTRUSTED_GID if (GRKERNSEC_TPE && !GRKERNSEC_TPE_INVERT) default GRKERNSEC_TPE_TRUSTED_GID if (GRKERNSEC_TPE && GRKERNSEC_TPE_INVERT) config GRKERNSEC_TPE_UNTRUSTED_GID int "GID for TPE-untrusted users" depends on GRKERNSEC_TPE && !GRKERNSEC_TPE_INVERT default 1005 help 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. config GRKERNSEC_TPE_TRUSTED_GID int "GID for TPE-trusted users" depends on GRKERNSEC_TPE && GRKERNSEC_TPE_INVERT default 1005 help Setting this GID determines what group TPE restrictions will be *disabled* for. If the sysctl option is enabled, a sysctl option with name "tpe_gid" is created. endmenu menu "Network Protections" depends on GRKERNSEC config GRKERNSEC_BLACKHOLE bool "TCP/UDP blackhole and LAST_ACK DoS prevention" default y if GRKERNSEC_CONFIG_AUTO depends on NET help 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. config GRKERNSEC_NO_SIMULT_CONNECT bool "Disable TCP Simultaneous Connect" default y if GRKERNSEC_CONFIG_AUTO depends on NET help 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. config GRKERNSEC_SOCKET bool "Socket restrictions" depends on NET help 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. config GRKERNSEC_SOCKET_ALL bool "Deny any sockets to group" depends on GRKERNSEC_SOCKET help 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. config GRKERNSEC_SOCKET_ALL_GID int "GID to deny all sockets for" depends on GRKERNSEC_SOCKET_ALL default 1004 help 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. config GRKERNSEC_SOCKET_CLIENT bool "Deny client sockets to group" depends on GRKERNSEC_SOCKET help 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. config GRKERNSEC_SOCKET_CLIENT_GID int "GID to deny client sockets for" depends on GRKERNSEC_SOCKET_CLIENT default 1003 help 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. config GRKERNSEC_SOCKET_SERVER bool "Deny server sockets to group" depends on GRKERNSEC_SOCKET help 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. config GRKERNSEC_SOCKET_SERVER_GID int "GID to deny server sockets for" depends on GRKERNSEC_SOCKET_SERVER default 1002 help 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. endmenu menu "Physical Protections" depends on GRKERNSEC config GRKERNSEC_DENYUSB bool "Deny new USB connections after toggle" default y if GRKERNSEC_CONFIG_AUTO depends on SYSCTL && USB_SUPPORT help 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. config GRKERNSEC_DENYUSB_FORCE bool "Reject all USB devices not connected at boot" select USB depends on GRKERNSEC_DENYUSB help 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. endmenu menu "Sysctl Support" depends on GRKERNSEC && SYSCTL config GRKERNSEC_SYSCTL bool "Sysctl support" default y if GRKERNSEC_CONFIG_AUTO help 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* config GRKERNSEC_SYSCTL_DISTRO bool "Extra sysctl support for distro makers (READ HELP)" depends on GRKERNSEC_SYSCTL && GRKERNSEC_IO help 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" config GRKERNSEC_SYSCTL_ON bool "Turn on features by default" default y if GRKERNSEC_CONFIG_AUTO depends on GRKERNSEC_SYSCTL help 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. endmenu menu "Logging Options" depends on GRKERNSEC config GRKERNSEC_FLOODTIME int "Seconds in between log messages (minimum)" default 10 help 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. config GRKERNSEC_FLOODBURST int "Number of messages in a burst (maximum)" default 6 help 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. endmenu