forked from Qortal/Brooklyn
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1206 lines
51 KiB
1206 lines
51 KiB
# |
|
# 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/<pid>/maps and /proc/<pid>/stat files will |
|
give no information about the addresses of its mappings if |
|
PaX features that rely on random addresses are enabled on the task. |
|
In addition to sanitizing this information and disabling other |
|
dangerous sources of information, this option causes reads of sensitive |
|
/proc/<pid> entries where the file descriptor was opened in a different |
|
task than the one performing the read. Such attempts are logged. |
|
This option also limits argv/env strings for suid/sgid binaries |
|
to 512KB to prevent a complete exhaustion of the stack entropy provided |
|
by ASLR. Finally, it places an 8MB stack resource limit on suid/sgid |
|
binaries to prevent alternative mmap layouts from being abused. |
|
|
|
If you use PaX it is essential that you say Y here as it closes up |
|
several holes that make full ASLR useless locally. |
|
|
|
|
|
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/<pid>/ipaddr support" |
|
default y if GRKERNSEC_CONFIG_AUTO |
|
help |
|
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. |
|
|
|
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
|
|
|