news FAQ papers features download misc mirrors mailinglist forum devel personal contact
84 Total Configurable Options
stealth networking support
CONFIG_IP_NF_MATCH_STEALTH
Enabling this option will drop all syn packets coming to unserved tcp
ports as well as all packets coming to unserved udp ports. If you
are using your system to route any type of packets (ie. via NAT)
you should put this module at the end of your ruleset, since it will
drop packets that aren't going to ports that are listening on your
machine itself, it doesn't take into account that the packet might be
destined for someone on your internal network if you're using NAT for
instance.
If you want to compile it as a module, say M here and read
Documentation/modules.txt. If unsure, say `N'.
Grsecurity
CONFIG_GRKERNSEC
If you say Y here, you will be able to configure many features that
will enhance the security of your system. It is highly recommended
that you say Y here and read through the help for each option so
you fully understand what it's doing and can evaluate its usefulness
for your machine.
Additional security levels
CONFIG_GRKERNSEC_LOW
Low additional security
-----------------------------------------------------------------------
If you choose this option, several of the grsecurity options will
be enabled that will give you greater protection against a number
of attacks, while assuring that none of your software will have any
conflicts with the additional security measures. If you run a lot of
unusual software, or you are having problems with the higher security
levels, you should say Y here. With this option, the following features
are enabled:
linking restrictions
fifo restrictions
secure fds
random pids
enforcing nproc on execve()
restricted dmesg
random ip ids
enforced chdir("/") on chroot
secure keymap loading
Medium additional security
-----------------------------------------------------------------------
If you say Y here, several features in addition to those included in the
low additional security level will be enabled. These features provide
even more security to your system, though in rare cases they may
be incompatible with very old or poorly written software. If you
enable this option, make sure that your auth service (identd) is
running as gid 10 (usually group wheel). With this option the following
features (in addition to those provided in the low additional security
level) will be enabled:
random tcp source ports
altered ping ids
failed fork logging
time change logging
signal logging
deny mounts in chroot
deny double chrooting
deny mknod in chroot
/proc restrictions with special gid set to 10 (usually wheel)
pax's random mmap
High additional security
----------------------------------------------------------------------
If you say Y here, many of the features of grsecurity will be enabled,
that will protect you against virtually all kinds of attacks against
your system. The much hightened security comes at a cost of an
increased chance of incompatabilities with rare software on your
machine. It is highly recommended that you view
and read about each option. Since
this security level enabled PaX, you should also view
and read about the PaX project. While
you are there, download chpax.c and run chpax -p on binaries that cause
problems with PaX. Also remember that since the /proc restrictions are
enabled, you must run your identd as group wheel (gid 10). The
grsecurity ACL system is also enabled in this level. To learn how to
correctly configure it, view the ACL documentation on
. This security level enables the following
features in addition to those listed in the low and medium security
levels:
grsecurity ACL system
additional /proc restrictions
signal restrictions in chroot
chmod restrictions in chroot
no ptrace in chroot
priority restrictions in chroot
PaX - random mmap, noexec on all memory pages, restricted mprotect
fixed mmap restrictions
mount/unmount/remount logging
restricted ptrace (only root and users in group wheel (gid 10) are
allowed to ptrace)
Customized additional security
CONFIG_GRKERNSEC_CUSTOM
If you say Y here, you will be able to configure every grsecurity
option, which allows you to enable many more features that aren't
covered in the basic security levels. These additional features include
TPE, socket restrictions, and the sysctl system for grsecurity. It is
advised that you read through the help for each option to determine its
usefulness in your situation.
OpenWall Non-executable Stack
CONFIG_GRKERNSEC_STACK
If you say Y here, your system will not allow execution of
code on the stack, making buffer overflow exploitation more difficult.
The code for this protection is taken from the Openwall patch for
linux 2.2 by Solar Designer. You can view his projects at
.
Exploits against your machine with this protection will have to dabble
in more obscure methods of exploitation(bss,got,heap..)
Gcc trampoline support
CONFIG_GRKERNSEC_STACK_GCC
If you say Y here, the system will support trampoline code along
with the stack protection. If you do not have any programs on
your system that require this (glibc 2.0 users must say YES to
this option) you may say no here.
PaX protection
CONFIG_GRKERNSEC_PAX
By design the IA-32 architecture does not allow for protecting
memory pages against execution, i.e. if a page is readable (such
as the stack or heap) it is also executable. There is a well
known exploit technique that makes use of this fact and a common
programming mistake where an attacker can introduce executable
code of his choice somewhere in the attacked program's memory
(typically the stack or the heap) and then execute it. If the
attacked program was running with different (typically higher)
privileges than that of the attacker, then he can elevate his
own privilege level (e.g. get a root shell, write to files for
which he does not have write access to, etc).
Since the implementation is software based, it comes with a
performance impact, you should evaluate your system carefully
before deciding to use this feature on production systems.
Enabling this feature will enforce the non-executable flag on
memory pages thereby making it harder to execute 'foreign' code
in a program. This will also break programs that rely on the
old behaviour and expect that dynamically allocated memory via
the malloc() family of functions is executable (which it is not).
Notable examples are the XFree86 4.x server, the java runtime
and wine.
NOTE: you can use the 'chpax' utility to enable/disable this
feature on a per file basis. chpax is available at
Emulate trampolines
CONFIG_GRKERNSEC_PAX_EMUTRAMP
There are some programs and libraries that for one reason or
another attempt to execute special small code snippets from
non-executable memory pages. Most notable examples are the
signal handler return code generated by the kernel itself and
the GCC trampolines.
If you enabled CONFIG_GRKERNSEC_PAX then such programs will no
longer work under your kernel. As a remedy you can say Y here
and use the 'chpax' utility to enable trampoline emulation for
the affected programs yet still have the protection provided by
CONFIG_GRKERNSEC_PAX. Alternatively you can say N here and use
the 'chpax' utility to disable CONFIG_GRKERNSEC_PAX for the
affected files. chpax is available at
NOTE: enabling this feature *may* open up a loophole in the
protection provided by CONFIG_GRKERNSEC_PAX that an attacker
could abuse. Therefore the best solution is to not have any
files on your system that would require this option. This can
be achieved by not using libc5 (which relies on the kernel
signal handler return code) and not using or rewriting programs
that make use of the nested function implementation of GCC.
Skilled users can just fix GCC itself so that it implements
nested function calls in a way that does not interfere with PaX.
Restrict mprotect()
CONFIG_GRKERNSEC_PAX_MPROTECT
Enabling this option will prevent programs from changing the
executable status of memory pages that were not originally
created as executable. The kernel will also prevent programs
from making read-only executable pages writable again.
You should say Y here to complete the protection provided by
the enforcement of the PAGE_EXEC flag (CONFIG_GRKERNSEC_PAX).
NOTE: you can use the 'chpax' utility to enable/disable this
feature on a per file basis. chpax is available at
Randomize mmap() base
CONFIG_GRKERNSEC_PAX_RANDMMAP
By saying Y here the kernel will somewhat randomize the address
space layout of programs at each execution (the top of the stack, the
base address for mmap() requests that do not specify one themselves
and the base address of dynamic ELF executables).
As a result all dynamically loaded libraries will appear at random
addresses and therefore be harder to exploit by a technique where
an attacker attempts to execute library code for his purposes
(e.g. spawn a shell from an exploited program that is running at
an elevated privilege level).
Furthermore, if a program is relinked as a dynamic ELF file, its
base address layout will be randomized as well, completing the full
randomization of the address space. Attacking such programs becomes
a guess game.
It is strongly recommended to say Y here even if CONFIG_GRKERNSEC_PAX
is not enabled as address space layout randomization has negligible
impact on performance yet it provides a very effective protection.
NOTE: you can use the 'chpax' utility to enable/disable this
feature on a per file basis. chpax is available at
Read-only kernel memory
CONFIG_GRKERNSEC_KMEM
If you say Y here, root will not be able to modify the contents of
kernel memory. If module support is removed in addition to enabling
this option, the ability of an attacker to insert foreign code into
a running kernel is removed.
Fixed mmap restrictions
CONFIG_GRKERNSEC_MMAPFIXED
If you say Y here, it will be impossible for an attacker to bypass the
PaX buffer overflow protection by mmaping an executable memory region
with a specific address set.
Proc Restrictions
CONFIG_GRKERNSEC_PROC
If you say Y here, the permissions of the /proc filesystem
will be altered to enhance system security and privacy. Depending
upon the options 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 as
a non-root user, you will have to run it as the group you specify here.
Restrict /proc to user only
CONFIG_GRKERNSEC_PROC_USER
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.
Restrict /proc to user and group
CONFIG_GRKERNSEC_PROC_USERGROUP
If you say Y here, you will be able to select a group that will be
able to view all processes, network-related information, and
kernel and symbol information. This option is useful if you want
to run identd as a non-root user.
Additional proc restrictions
CONFIG_GRKERNSEC_PROC_ADD
If you say Y here, additional restrictions will be placed on
/proc that keep normal users from viewing cpu and device information.
Dmesg(8) Restriction
CONFIG_GRKERNSEC_DMESG
If you say Y here, non-root users will not be able to use dmesg(8)
to view up to the last 4kb of messages in the kernel's log buffer.
If the sysctl option is enabled, a sysctl option with name "dmesg" is
created.
Linking restrictions
CONFIG_GRKERNSEC_LINK
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-writeable +t directories (i.e. /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.
FIFO restrictions
CONFIG_GRKERNSEC_FIFO
If you say Y here, users will not be able to write to FIFOs they don't
own in world-writeable +t directories (i.e. /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.
Secure file descriptors
CONFIG_GRKERNSEC_FD
If you say Y here, binaries will be protected from data spoofing
attacks (eg. making a program read /etc/shadow). The patches do this
by opening up /dev/null to any of the stdin, stdout, stderr file descriptors
for binaries that are open. If the sysctl option is enabled, a sysctl
option with name "secure_fds" is created.
Exec process limiting
CONFIG_GRKERNSEC_EXECVE
If you say Y here, users with a resource limit on processes will
have the value checked during execve() calls. The current system
only checks the system limit during fork() calls. If the sysctl option
is enabled, a sysctl option with name "execve_limiting" is created.
Fork-bombing protection
CONFIG_GRKERNSEC_FORKBOMB
If you say Y here, you will be able to configure a group to add to users
on your system that you want to be unable to fork-bomb the system.
You will be able to specify a maximum process limit for the user and
set a rate limit for all forks under their uid. (Fork-bombing is a
tactic used by attackers that can be enacted in two ways, (1) loading
up thousands of processes until the system can't take any more (this
method can be stopped outside of the kernel with PAM, however we place
protection for it in the kernel to be more complete and reduce overhead),
and (2), by forking processes at a rapid rate, and then killing them
off, which cannot be protected against in the same way at tactic 1)
The rate limit is specified in forks allowed per second. Set this
limit low enough to stop tactic 2, but high enough to allow for
normal operation. The protection will kill the offending process.
If the sysctl option is enabled, a sysctl option with name
"fork_bomb_prot" is created.
Max processes for fork-bomb protection
CONFIG_GRKERNSEC_FORKBOMB_MAX
Here you can configure the maximum number of processes users in the
fork-bomb protected group can run. I would not recommend setting a
value lower than 8, since some programs like man(1) spawn up to 8
processes to run. The default value should be fine for most purposes.
If the sysctl option is enabled, a sysctl option with name
"fork_bomb_max" is created.
Forks allowed per second
CONFIG_GRKERNSEC_FORKBOMB_SEC
Here you can specify the maximum number of forks allowed per second.
You don't want to set this value too low, or else you'll hinder
normal operation of your system. The default value should be fine for
most users. If the sysctl option is enabled, a sysctl option with name
"fork_bomb_sec" is created.
Group for fork-bomb protection
CONFIG_GRKERNSEC_FORKBOMB_GID
Here you can choose the GID to enable fork-bomb protection for.
Remember to add the users you want protection enabled for to the GID
specified here. If the sysctl option is enabled, whatever you choose
here won't matter. You'll have to specify the GID in your bootup
script by echoing the GID to the proper /proc entry. View the help
on the sysctl option for more information. If the sysctl option is
enabled, a sysctl option with name "fork_bomb_gid" is created.
Single group for auditing
CONFIG_GRKERNSEC_AUDIT_GROUP
If you say Y here, the exec, chdir, (un)mount, and ipc 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.
GID for auditing
CONFIG_GRKERNSEC_AUDIT_GID
Here you can choose the GID that will be the target of kernel auditing.
Remember to add the users you want to log to the GID specified here.
If the sysctl option is enabled, whatever you choose here won't matter.
You'll have to specify the GID in your bootup script by echoing the GID
to the proper /proc entry. View the help on the sysctl option for more
information. If the sysctl option is enabled, a sysctl option with name
"audit_gid" is created.
Chdir logging
CONFIG_GRKERNSEC_AUDIT_CHDIR
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.
(Un)Mount logging
CONFIG_GRKERNSEC_AUDIT_MOUNT
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.
IPC logging
CONFIG_GRKERNSEC_AUDIT_IPC
If you say Y here, creation and removal of message queues, semaphores,
and shared memory will be logged. If the sysctl option is enabled, a
sysctl option with name "audit_ipc" is created.
Exec logging
CONFIG_GRKERNSEC_EXECLOG
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.
Set*id logging
CONFIG_GRKERNSEC_SUID
If you say Y here, all set*id() calls will be logged. Such information
could be useful when detecting a possible intrusion attempt. This
option can produce a lot of logs on an active system. If the sysctl
option is enabled, a sysctl option with name "suid_logging" is created.
Log set*ids to root
CONFIG_GRKERNSEC_SUID_ROOT
If you say Y here, only set*id() calls where a user is changing to the
gid or uid of the root user will be logged. Such information
could be useful when detecting a possible intrusion attempt. This
option will produce less logs than logging all calls. If the sysctl
option is enabled, a sysctl option with name "suid_root_logging" is
created.
Altered default IPC permissions
CONFIG_GRKERNSEC_IPC
If you say Y here, the default permissions for IPC objects will be
set based on the filesystem umask of the user creating the object.
By default linux sets the permissions to ugo+rwx, which can be
a security problem if the application doesn't explicitly set the
permissions of the IPC object. Since this change affects programs
using IPC, it might break some programs that are expecting the
default permission behavior. It is known to break Apache 1.3.22.
Signal logging
CONFIG_GRKERNSEC_SIGNAL
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.
BSD-style coredumps
CONFIG_GRKERNSEC_COREDUMP
If you say Y here, linux will use a style similar to BSD for
coredumps, core.processname. Not a security feature, just
a useful one. If the sysctl option is enabled, a sysctl option with
name "coredump" is created.
Fork failure logging
CONFIG_GRKERNSEC_FORKFAIL
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.
Time change logging
CONFIG_GRKERNSEC_TIME
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.
Secure keymap loading
CONFIG_GRKERNSEC_KBMAP
If you say Y here, KDSKBENT and KDSKBSENT ioctl calls being
called by unprivileged users will be denied. If you answer N,
everyone with access to the console will be able to modify keyboard
bindings. If the sysctl option is enabled, a sysctl option with name
"secure_kbmap" is created.
Chroot jail restrictions
CONFIG_GRKERNSEC_CHROOT
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.
Restricted signals in chroot
CONFIG_GRKERNSEC_CHROOT_SIG
If you say Y here, processes inside a chroot will not be able to send
signals outside of the chroot. The only signals allowed are null
signals which perform no action, and the parent process sending
a certain signal to its child. If the sysctl option is enabled, a
sysctl option with name "chroot_restrict_sigs" is created.
Deny mounts in chroot
CONFIG_GRKERNSEC_CHROOT_MOUNT
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.
Deny double-chroots
CONFIG_GRKERNSEC_CHROOT_DOUBLE
If you say Y here, processes inside a chroot will not be able to chroot
again. 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.
Enforce chdir("/") on all chroots
CONFIG_GRKERNSEC_CHROOT_CHDIR
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.
Deny (f)chmod +s in chroot
CONFIG_GRKERNSEC_CHROOT_CHMOD
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.
Deny mknod in chroot
CONFIG_GRKERNSEC_CHROOT_MKNOD
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
anyhing 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.
Deny ptraces in chroot
CONFIG_GRKERNSEC_CHROOT_PTRACE
If you say Y here, processes inside a chroot will not be able to ptrace
other processes. Ptracing a process allows one to attach and alter the
flow of execution for the process. It is strongly recommended that you
say Y here. If the sysctl option is enabled, a sysctl option with name
"chroot_deny_ptrace" is created.
Restrict priority changes in chroot
CONFIG_GRKERNSEC_CHROOT_NICE
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.
Log all execs within chroot
CONFIG_GRKERNSEC_CHROOT_EXECLOG
If you say Y here, all executions inside a chroot jail will be logged
to syslog. If the sysctl option is enabled, a sysctl option with name
"chroot_execlog" is created.
Chroot jail capability restrictions
CONFIG_GRKERNSEC_CHROOT_CAPS
If you say Y here, the capabilities on all root processes within a
chroot jail will be lowered to stop module insertion, raw i/o,
system and net admin tasks, rebooting the system, modifying immutable
files, 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.
Trusted path execution
CONFIG_GRKERNSEC_TPE
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 writeable only by root. If the sysctl option
is enabled, a sysctl option with name "tpe" is created.
Group for trusted path execution
CONFIG_GRKERNSEC_TPE_GID
Here you can choose the GID to enable trusted path protection for.
Remember to add the users you want protection enabled for to the GID
specified here. If the sysctl option is enabled, whatever you choose
here won't matter. You'll have to specify the GID in your bootup
script by echoing the GID to the proper /proc entry. View the help
on the sysctl option for more information. If the sysctl option is
enabled, a sysctl option with name "tpe_gid" is created.
Partially restrict non-root users
CONFIG_GRKERNSEC_TPE_ALL
If you say Y here, All non-root users other than the ones in the
group specified in the main TPE option will only be allowed to
execute files in directories they own that are not group or
world-writeable, or in directories owned by root and writeable only by
root. If the sysctl option is enabled, a sysctl option with name
"tpe_restrict_all" is created.
Trusted path execution glibc protection
CONFIG_GRKERNSEC_TPE_GLIBC
If you say Y here, all non-root users executing any files while
glibc specific environment variables such as LD_PRELOAD are set,
will have their environment cleared of these variables, since they
could be used to evade the trusted path execution protection. It also
protects against evasion through executing the dynamic linker to run a
rogue binary. It is recommended you say Y here also. If the sysctl
option is enabled, a sysctl option with name "tpe_glibc" is created.
Ptrace logging
CONFIG_GRKERNSEC_AUDIT_PTRACE
If you say Y here, all successful ptraces will be logged. Ptraces are
special operations performed when programs like strace or gdb are run.
They have also been the focus of some kernel vulnerabilities. If the
sysctl option is enabled, a sysctl option with name "audit_ptrace" is
created.
Restricted ptrace
CONFIG_GRKERNSEC_PTRACE
If you say Y here, no one but root will be able to ptrace processes.
Tracing syscalls inside the kernel will also be disabled. If the
sysctl option is enabled, a sysctl option with name "restrict_ptrace"
is created.
Allow ptrace for group
CONFIG_GRKERNSEC_PTRACE_GROUP
If you say Y here, you will be able to choose a GID of whose users
will be able to ptrace. If the sysctl option is enabled, a sysctl
option with name "allow_ptrace_group" is created.
GID for ptrace
CONFIG_GRKERNSEC_PTRACE_GID
Here you can choose the GID of whose users will be able to ptrace.
Remember to add the users you want ptrace enabled for to the GID
specified here. If the sysctl option is enabled, whatever you choose
here won't matter. You'll have to specify the GID in your bootup
script by echoing the GID to the proper /proc entry. View the help
on the sysctl option for more information. If the sysctl option is
enabled, a sysctl option with name "ptrace_gid" is created.
Randomized PIDs
CONFIG_GRKERNSEC_RANDPID
If you say Y here, all PIDs created on the system will be
pseudo-randomly generated. This is extremely effective along
with the /proc restrictions to disallow an attacker from guessing
pids of daemons, etc. PIDs are also used in some cases as part
of a naming system for temporary files, so this option would keep
those filenames from being predicted as well. We also use code
to make sure that PID numbers aren't reused too soon. If the sysctl
option is enabled, a sysctl option with name "rand_pids" is created.
Limit uid/gid changes to root
CONFIG_GRKERNSEC_TTYROOT
If you say Y here, you will be able choose from three option that
will allow you to restrict access to the root account by console
type. These options should only be enabled if you are sure of what
you're doing. Also note that they only apply to processes that have
ttys, which generally involves some kind of user-interaction. The
options are basically in place to keep users on a system who have a
(stolen) password for root from using it unless their console
credentials match.
Deny physical consoles (tty)
CONFIG_GRKERNSEC_TTYROOT_PHYS
If you say Y here, access to root from physical consoles will be
denied. This is only recommended for rare cases where you will
never need to be physically at the machine. If the sysctl option
is enabled, a sysctl option with name "deny_phys_root" is created.
Deny serial consoles (ttyS)
CONFIG_GRKERNSEC_TTYROOT_SERIAL
If you say Y here, access to root from serial consoles will be
denied. Most people can say Y here, since most don't use serial
devices for their console access. If you are unsure, say N. If
the sysctl option is enabled, a sysctl option with name
"deny_serial_root" is created.
Deny pseudo consoles (pty)
CONFIG_GRKERNSEC_TTYROOT_PSEUDO
If you say Y here, access to root from pseudo consoles will be
denied. Pseudo consoles include consoles from telnet, ssh, or any other
kind of interactive shell initiated from the network. Pseudo consoles
also include any terminals you use in XFree86. If you will only be
accessing the machine for root access from the physical console, you
can say Y here. Only say Y here if you're sure of what you're doing.
If the sysctl option is enabled, a sysctl option with name
"deny_pseudo_root" is created.
Randomized IP IDs
CONFIG_GRKERNSEC_RANDID
If you say Y here, all the id field on all outgoing packets
will be randomized. This hinders os fingerprinters and
keeps your machine from being used as a bounce for an untraceable
portscan. Ids are used for fragmented packets, fragments belonging
to the same packet have the same id. By default linux only
increments the id value on each packet sent to an individual host.
We use a port of the OpenBSD random ip id code to achieve the
randomness, while keeping the possibility of id duplicates to
near none. If the sysctl option is enabled, a sysctl option with name
"rand_ip_ids" is created.
Randomized TCP source ports
CONFIG_GRKERNSEC_RANDSRC
If you say Y here, situations where a source port is generated on the
fly for the TCP protocol (ie. with connect() ) will be altered so that
the source port is generated at random, instead of a simple incrementing
algorithm. If the sysctl option is enabled, a sysctl option with name
"rand_tcp_src_ports" is created.
Randomized RPC XIDs
CONFIG_GRKERNSEC_RANDRPC
If you say Y here, the method of determining XIDs for RPC requests will
be randomized, instead of using linux's default behavior of simply
incrementing the XID. If you want your RPC connections to be more
secure, say Y here. If the sysctl option is enabled, a sysctl option
with name "rand_rpc" is created.
Altered Ping IDs
CONFIG_GRKERNSEC_RANDPING
If you say Y here, the way Linux handles echo replies will be changed
so that the reply uses an ID equal to the ID of the echo request.
This will help in confusing OS detection. If the sysctl option is
enabled, a sysctl option with name "altered_pings" is created.
Randomized TTL
CONFIG_GRKERNSEC_RANDTTL
If you say Y here, your TTL (time to live) for packets will be set at
random, with a base of the sysctl ttl default, to further confuse OS
detection. If the sysctl option is enabled, a sysctl option with name
"rand_ttl" is created.
Socket restrictions
CONFIG_GRKERNSEC_SOCKET
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.
Deny all socket access
CONFIG_GRKERNSEC_SOCKET_ALL
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.
Group for disabled socket access
CONFIG_GRKERNSEC_SOCKET_ALL_GID
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, whatever you choose
here won't matter. You'll have to specify the GID in your bootup
script by echoing the GID to the proper /proc entry. View the help
on the sysctl option for more information. If the sysctl option is
enabled, a sysctl option with name "socket_all_gid" is created.
Deny all client socket access
CONFIG_GRKERNSEC_SOCKET_CLIENT
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.
Group for disabled client socket access
CONFIG_GRKERNSEC_SOCKET_CLIENT_GID
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, whatever you
choose here won't matter. You'll have to specify the GID in your bootup
script by echoing the GID to the proper /proc entry. View the help
on the sysctl option for more information. If the sysctl option is
enabled, a sysctl option with name "socket_client_gid" is created.
Deny all server socket access
CONFIG_GRKERNSEC_SOCKET_SERVER
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.
Group for disabled server socket access
CONFIG_GRKERNSEC_SOCKET_SERVER_GID
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, whatever you
choose here won't matter. You'll have to specify the GID in your bootup
script by echoing the GID to the proper /proc entry. View the help
on the sysctl option for more information. If the sysctl option is
enabled, a sysctl option with name "socket_server_gid" is created.
Sysctl support
CONFIG_GRKERNSEC_SYSCTL
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 are disabled by default. Please note that this option could
reduce the effectiveness of the added security of this patch if an ACL
system is not put in place. Your init scripts should be read-only, and
root should not have access to adding modules or performing raw i/o
operations. 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*
Grsecurity ACL System
CONFIG_GRKERNSEC_ACL
If you say Y here, you enable the Access Control List system for
grsecurity. Unlike many other popular ACL systems, it allows both
process and file ACLs. To use the ACL system, you must also download the
userspace code and documentation off the grsecurity website:
You will then need to run gradm setup to set
your password and create your config files.
Enabled denied capability logging
CONFIG_GRKERNSEC_ACL_CAPLOG
If you say Y here, logs will be produced when a root-owned process does
not have a needed capability raised in his set. This information is
useful when creating ACLs for your system.
Seconds in between log messages
CONFIG_GRKERNSEC_FLOODTIME
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.
Enable ACL Debugging Messages
CONFIG_GR_DEBUG
This option allows the grsecurity ACL system to print debugging messages
as an aid to finding problems in your ACL sets.
Enable Extra ACL Debugging Messages
CONFIG_GR_SUPERDEBUG
This option allows you to enable additional debugging messages that can
also help you in finding problems in your ACL sets or to gain a better
understanding of the internal workings of the ACL system.
Path to gradm
CONFIG_GRADM_PATH
This should be set to the path of the gradm binary installed on your
system. If gradm is not yet installed on your system, download
gradm from and follow the directions in the
README.
Maximum tries before password lockout
CONFIG_GR_MAXTRIES
This option enforces the maximum number of times a user can attempt
to authorize themselves with the grsecurity ACL 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.
Time to wait after max password tries, in seconds
CONFIG_GR_TIMEOUT
This option specifies the time the user must wait after attempting to
authorize to the ACL system with the maximum number of invalid
passwords. The higher the number, the harder it will be to brute-force
a password.