#
# 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.
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 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_JIT_HARDEN
bool "Harden BPF JIT against spray attacks"
default y if GRKERNSEC_CONFIG_AUTO
depends on BPF_JIT && X86
help
If you say Y here, the native code generated by the kernel's Berkeley
Packet Filter (BPF) JIT engine will be hardened against JIT-spraying
attacks that attempt to fit attacker-beneficial instructions in
32bit immediate fields of JIT-generated native instructions. The
attacker will generally aim to cause an unintended instruction sequence
of JIT-generated native code to execute by jumping into the middle of
a generated instruction. This feature effectively randomizes the 32bit
immediate constants present in the generated code to thwart such attacks.
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_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"
select PAX_USERCOPY_SLABS
default y if GRKERNSEC_CONFIG_AUTO
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
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.
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.
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 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. 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_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_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_RANDNET
bool "Larger entropy pools"
default y if GRKERNSEC_CONFIG_AUTO
help
If you say Y here, the entropy pools used for many features of Linux
and grsecurity will be doubled in size. Since several grsecurity
features use additional randomness, it is recommended that you say Y
here. Saying Y here has a similar effect as modifying
/proc/sys/kernel/random/poolsize.
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.
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