mirror of
https://github.com/Qortal/Brooklyn.git
synced 2025-01-30 23:02:18 +00:00
2a709f28fa
* 0day explit mitigation * Memory corruption prevention * Privilege escalation prevention * Buffer over flow prevention * File System corruption defense * Thread escape prevention This may very well be the most intensive inclusion to BrooklynR. This will not be part of an x86 suite nor it will be released as tool kit. The security core toolkit will remain part of kernel base.
1207 lines
51 KiB
Plaintext
1207 lines
51 KiB
Plaintext
#
|
|
# 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
|