Install Stable:
Download stable patch3.0-3.2.63
Last updated: 09/28/14

Test:
Download test patch3.0-3.16.3
Last updated: 09/28/14
Grsecurity
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 the features and can evaluate their usefulness for your machine.
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
random pids
enforcing nproc on execve()
restricted dmesg
random ip ids
enforced chdir("/") on chroot
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
failed fork logging
time change logging
signal logging
deny mounts in chroot
deny double chrooting
deny sysctl writes in chroot
deny mknod in chroot
deny access to abstract AF_UNIX sockets out of chroot
deny pivot_root in chroot
denied writes of /dev/kmem, /dev/mem, and /dev/port
/proc restrictions with special gid set to 10 (usually wheel)
address space layout randomization
removal of addresses from /proc/<pid>/[maps|stat]
High additional security
If you say Y here, many of the features of grsecurity will be enabled, that will protect you against many kinds of attacks against your system. The heightened security comes at a cost of an increased chance of incompatibilities with rare software on your machine. Since this security level enables PaX, you should view <http://pax.grsecurity.net> and read about the PaX project. While you are there, download chpax and run it 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). This security level enables the following features in addition to those listed in the low and medium security levels:

additional /proc restrictions
chmod restrictions in chroot
no signals, ptrace, or viewing processes outside of chroot
capability restrictions in chroot
deny fchdir out of chroot
priority restrictions in chroot
segmentation-based implementation of PaX
mprotect restrictions
kernel stack randomization
mount/unmount/remount logging
kernel symbol hiding
Customized additional security
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.
Support soft mode
Enabling this option will allow you to run PaX in soft mode, that is, PaX features will not be enforced by default, only on executables marked explicitly. You must also enable PT_PAX_FLAGS support as it is the only way to mark executables for soft mode use.

Soft mode can be activated by using the "pax_softmode=1" kernel command line option on boot. Furthermore you can control various PaX features at runtime via the entries in /proc/sys/kernel/pax.
Use legacy ELF header marking
Enabling this option will allow you to control PaX features on a per executable basis via the 'chpax' utility available at http://pax.grsecurity.net/. The control flags will be read from an otherwise reserved part of the ELF header. This marking has numerous drawbacks (no support for soft-mode, toolchain does not know about the non-standard use of the ELF header) therefore it has been deprecated in favour of PT_PAX_FLAGS support.

You should enable this option only if your toolchain does not yet support the new control flag location (PT_PAX_FLAGS) or you still have applications not marked by PT_PAX_FLAGS.

Note that if you enable PT_PAX_FLAGS marking support as well, it will override the legacy EI_PAX marks.
Use ELF program header marking
Enabling this option will allow you to control PaX features on a per executable basis via the 'paxctl' utility available at http://pax.grsecurity.net/. The control flags will be read from a PaX specific ELF program header (PT_PAX_FLAGS). This marking has the benefits of supporting both soft mode and being fully integrated into the toolchain (the binutils patch is available from http://pax.grsecurity.net).

Note that if you enable the legacy EI_PAX marking support as well, it will be overridden by the PT_PAX_FLAGS marking.
MAC system integration
Mandatory Access Control systems have the option of controlling PaX flags on a per executable basis, choose the method supported by your particular system.

- "none": if your MAC system does not interact with PaX,
- "direct": if your MAC system defines pax_set_flags() itself,
- "hook": if your MAC system uses the pax_set_flags_func callback.

NOTE: this option is for developers/integrators only.
Enforce non-executable pages
By design some architectures do not allow for protecting memory pages against execution or even if they do, Linux does not make use of this feature. In practice this means that 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 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).

Enabling this option will let you choose from various features that prevent the injection and execution of '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.
Paging based non-executable pages
This implementation is based on the paging feature of the CPU. On i386 it has a variable performance impact on applications depending on their memory usage pattern. You should carefully test your applications before using this feature in production. On alpha, parisc, sparc and sparc64 there is no performance impact. On ppc there is a slight performance impact.
Segmentation based non-executable pages
This implementation is based on the segmentation feature of the CPU and has little performance impact, however applications will be limited to a 1.5 GB address space instead of the normal 3 GB.
Emulate trampolines
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_PAGEEXEC or CONFIG_GRKERNSEC_PAX_SEGMEXEC then such programs will no longer work under your kernel.

As a remedy you can say Y here and use the 'chpax' or 'paxctl' utilities to enable trampoline emulation for the affected programs yet still have the protection provided by the non-executable pages.

On parisc and ppc you MUST enable this option and EMUSIGRT as well, otherwise your system will not even boot.

Alternatively you can say N here and use the 'chpax' or 'paxctl' utilities to disable CONFIG_GRKERNSEC_PAX_PAGEEXEC and CONFIG_GRKERNSEC_PAX_SEGMEXEC for the affected files.

NOTE: enabling this feature *may* open up a loophole in the protection provided by non-executable pages 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.
Automatically emulate sigreturn trampolines
Enabling this option will have the kernel automatically detect and emulate signal return trampolines executing on the stack that would otherwise lead to task termination.

This solution is intended as a temporary one for users with legacy versions of libc (libc5, glibc 2.0, uClibc before 0.9.17, Modula-3 runtime, etc) or executables linked to such, basically everything that does not specify its own SA_RESTORER function in normal executable memory like glibc 2.1+ does.

On parisc and ppc you MUST enable this option, otherwise your system will not even boot.

NOTE: this feature cannot be disabled on a per executable basis and since it *does* open up a loophole in the protection provided by non-executable pages, the best solution is to not have any files on your system that would require this option.
Restrict mprotect()
Enabling this option will prevent programs from
  • changing the executable status of memory pages that were not originally created as executable,
  • making read-only executable pages writable again,
  • creating executable pages from anonymous memory.
You should say Y here to complete the protection provided by the enforcement of non-executable pages.

NOTE: you can use the 'chpax' utility to control this feature on a per file basis. chpax is available at <http://pax.grsecurity.net>
Disallow ELF text relocations
Non-executable pages and mprotect() restrictions are effective in preventing the introduction of new executable code into an attacked task's address space. There remain only two venues for this kind of attack: if the attacker can execute already existing code in the attacked task then he can either have it create and mmap() a file containing his code or have it mmap() an already existing ELF library that does not have position independent code in it and use mprotect() on it to make it writable and copy his code there. While protecting against the former approach is beyond PaX, the latter can be prevented by having only PIC ELF libraries on one's system (which do not need to relocate their code). If you are sure this is your case, then enable this option otherwise be careful as you may not even be able to boot or log on your system (for example, some PAM modules are erroneously compiled as non-PIC by default).

NOTE: if you are using dynamic ELF executables (as suggested when using ASLR) then you must have made sure that you linked your files using the PIC version of crt1 (the et_dyn.zip package referenced there has already been updated to support this).
Enforce non-executable kernel pages
This is the kernel land equivalent of PAGEEXEC and MPROTECT, that is, enabling this option will make it harder to inject and execute 'foreign' code in kernel memory itself.
Address Space Layout Randomization
Many if not most exploit techniques rely on the knowledge of certain addresses in the attacked program. The following options will allow the kernel to apply a certain amount of randomization to specific parts of the program thereby forcing an attacker to guess them in most cases. Any failed guess will most likely crash the attacked program which allows the kernel to detect such attempts and react on them. PaX itself provides no reaction mechanisms, instead it is strongly encouraged that you make use of grsecurity's built-in crash detection features or develop one yourself.

By saying Y here you can choose to randomize the following areas:
  • top of the task's kernel stack
  • top of the task's userland stack
  • base address for mmap() requests that do not specify one (this includes all libraries)
  • base address of the main executable
It is strongly recommended to say Y here as address space layout randomization has negligible impact on performance yet it provides a very effective protection.

NOTE: you can use the 'chpax' or 'paxctl' utilities to control most of these features on a per file basis.
Randomize kernel stack base
By saying Y here the kernel will randomize every task's kernel stack on every system call. This will not only force an attacker to guess it but also prevent him from making use of possible leaked information about it.

Since the kernel stack is a rather scarce resource, randomization may cause unexpected stack overflows, therefore you should very carefully test your system. Note that once enabled in the kernel configuration, this feature cannot be disabled on a per file basis.
Randomize user stack base
By saying Y here the kernel will randomize every task's userland stack. The randomization is done in two steps where the second one may apply a big amount of shift to the top of the stack and cause problems for programs that want to use lots of memory (more than 2.5 GB if SEGMEXEC is not active, or 1.25 GB when it is). For this reason the second step can be controlled by 'chpax' or 'paxctl' on a per file basis.
Randomize ET_EXEC base
By saying Y here the kernel will randomize the base address of normal ET_EXEC ELF executables as well. This is accomplished by mapping the executable in memory in a special way which also allows for detecting attackers who attempt to execute its code for their purposes. Since this special mapping causes performance degradation and the attack detection may create false alarms as well, you should carefully test your executables when this feature is enabled.

This solution is intended only as a temporary one until you relink your programs as a dynamic ELF file.

NOTE: you can use the 'chpax' or 'paxctl' utilities to control this feature on a per file basis.
Allow ELF ET_EXEC text relocations
On some architectures like the alpha there are incorrectly created applications that require text relocations and would not work without enabling this option. If you are an alpha user, you should enable this option and disable it once you have made sure that none of your applications need it.
Automatically emulate ELF PLT
Enabling this option will have the kernel automatically detect and emulate the Procedure Linkage Table entries in ELF files. On some architectures such entries are in writable memory, and become non-executable leading to task termination. Therefore it is mandatory that you enable this option on alpha, parisc, ppc, sparc and sparc64, otherwise your system would not even boot.

NOTE: this feature *does* open up a loophole in the protection provided by the non-executable pages, therefore the proper solution is to modify the toolchain to produce a PLT that does not need to be writable.
Randomize mmap() base
By saying Y here the kernel will use a randomized base address for mmap() requests that do not specify one themselves. 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 will be randomized as well, completing the full randomization of the address space layout. Attacking such programs becomes a guess game. You can find an example of doing this at <http://pax.grsecurity.net/et_dyn.zip> and practical samples at <http://www.grsecurity.net/grsec-gcc-specs.tar.gz> .

NOTE: you can use the 'chpax' or 'paxctl' utilities to control this feature on a per file basis.
Deny writing to /dev/kmem, /dev/mem, and /dev/port
If you say Y here, /dev/kmem and /dev/mem won't be allowed to be written to via mmap or otherwise to modify the running kernel. /dev/port will also not be allowed to be opened. If you have module support disabled, enabling this will close up four ways that are currently used to insert malicious code into the running kernel. Even with all these features 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 privileged I/O granted by ioperm/iopl. If you are not using XFree86, you may be able to stop this additional case by enabling the 'Disable privileged I/O' option. Though nothing legitimately writes to /dev/kmem, XFree86 does need to write to /dev/mem, but only to video memory, which is the only writing we allow in this case. If /dev/kmem or /dev/mem are mmaped without PROT_WRITE, they will not be allowed to mprotect it with PROT_WRITE later. It is highly recommended that you say Y here if you meet all the conditions above.
Disable privileged I/O
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 CONFIG_RTC is enabled if this option is enabled, to ensure that hwclock operates correctly. XFree86 still will not operate correctly with this option enabled, so DO NOT CHOOSE Y IF YOU USE XFree86. If you use XFree86 and you still want to protect your kernel against modification, use the RBAC system.
Hide kernel symbols
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. This option is only effective provided the following conditions are met:

1) The kernel using grsecurity is not precompiled by some distribution
2) You are using the RBAC system and hiding other files such as your kernel image and System.map
3) You have the additional /proc restrictions enabled, which removes /proc/kcore

If the above conditions are met, this option will aid to provide a useful protection against local and remote kernel exploitation of overflows and arbitrary read/write vulnerabilities.
/proc/<pid>/ipaddr support
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.
Proc Restrictions
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
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
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.
Remove addresses from /proc/pid/[maps|stat]
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.
If you use PaX it is greatly recommended that you say Y here as it
closes up a hole that makes the full ASLR useless for suid
binaries.
Additional proc restrictions
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
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
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 (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
If you say Y here, users will not be able to write to FIFOs they don't
own in world-writable +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.
Enforce RLIMIT_NPROC on execs
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.
Single group for auditing
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
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
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
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
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
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.
Resource logging
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.
Signal logging
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.
Fork failure logging
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
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.
ELF text relocations logging
If you say Y here, text relocations will be logged with the filename
of the offending library or binary. The purpose of the feature is
to help Linux distribution developers get rid of libraries and
binaries that need text relocations which hinder the future progress
of PaX. Only Linux distribution developers should say Y here, and
never on a production machine, as this option creates an information
leak that could aid an attacker in defeating the randomization of
a single memory region. If the sysctl option is enabled, a sysctl
option with name "audit_textrel" is created.
Chroot jail restrictions
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.
Deny access to abstract AF_UNIX sockets out of chroot
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.
Deny shmat() out of chroot
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.
Protect outside processes
If you say Y here, processes inside a chroot will not be able to
kill, send signals with fcntl, ptrace, capget, setpgid, getpgid,
getsid, or view any process outside of the chroot. If the sysctl
option is enabled, a sysctl option with name "chroot_findtask" is
created.
Deny mounts in chroot
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 pivot_root in chroot
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.
Deny double-chroots
If you say Y here, processes inside a chroot will not be able to chroot
again outside of 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.
Deny fchdir outside of chroot
If you say Y here, a well-known method of breaking chroots by fchdir'ing
to a file descriptor of the chrooting process that points to a directory
outside the filesystem will be stopped. If the sysctl option
is enabled, a sysctl option with name "chroot_deny_fchdir" is created.
Enforce chdir("/") on all chroots
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
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
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.
Restrict priority changes in chroot
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
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.
Deny sysctl writes in chroot
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.
Chroot jail capability restrictions
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, 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.
Trusted path execution
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.
Group for trusted path execution
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
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-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.
Randomized PIDs
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.
Larger entropy pools
If you say Y here, the entropy pools used for many features of Linux
and grsecurity will be doubled in size. Since several grsecurity
features use additional randomness, it is recommended that you say Y
here. Saying Y here has a similar effect as modifying
/proc/sys/kernel/random/poolsize.
Randomized TCP source ports
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.
Socket restrictions
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
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
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
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
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
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
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
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*
Number of burst messages
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.
Seconds in between log messages
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.
Hide kernel processes
If you say Y here, when the RBAC system is enabled via gradm -E,
an additional ACL will be passed to the kernel that hides all kernel
processes. These processes will only be viewable by the authenticated
admin, or processes that have viewing access set.
Maximum tries before password lockout
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.
Time to wait after max password tries, in seconds
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.

Site design by Hal Bergman