#
# grecurity configuration
#

menu "Grsecurity"

config GRKERNSEC
	bool "Grsecurity"
	select CRYPTO
	select CRYPTO_SHA256
	help
	  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 that you fully understand the features and
	  can evaluate their usefulness for your machine.

choice
	prompt "Security Level"
	depends on GRKERNSEC
	default GRKERNSEC_CUSTOM

config GRKERNSEC_LOW
	bool "Low"
	select GRKERNSEC_LINK
	select GRKERNSEC_FIFO
	select GRKERNSEC_RANDNET
	select GRKERNSEC_DMESG
	select GRKERNSEC_CHROOT
	select GRKERNSEC_CHROOT_CHDIR

	help
	  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
	  - Restricted dmesg
	  - Enforced chdir("/") on chroot
	  - Runtime module disabling

config GRKERNSEC_MEDIUM
	bool "Medium"
	select PAX
	select PAX_EI_PAX
	select PAX_PT_PAX_FLAGS
	select PAX_HAVE_ACL_FLAGS
	select GRKERNSEC_PROC_MEMMAP if (PAX_NOEXEC || PAX_ASLR)
	select GRKERNSEC_CHROOT
	select GRKERNSEC_CHROOT_SYSCTL
	select GRKERNSEC_LINK
	select GRKERNSEC_FIFO
	select GRKERNSEC_DMESG
	select GRKERNSEC_RANDNET
	select GRKERNSEC_FORKFAIL
	select GRKERNSEC_TIME
	select GRKERNSEC_SIGNAL
	select GRKERNSEC_CHROOT
	select GRKERNSEC_CHROOT_UNIX
	select GRKERNSEC_CHROOT_MOUNT
	select GRKERNSEC_CHROOT_PIVOT
	select GRKERNSEC_CHROOT_DOUBLE
	select GRKERNSEC_CHROOT_CHDIR
	select GRKERNSEC_CHROOT_MKNOD
	select GRKERNSEC_PROC
	select GRKERNSEC_PROC_USERGROUP
	select PAX_RANDUSTACK
	select PAX_ASLR
	select PAX_RANDMMAP
	select PAX_REFCOUNT if (X86 || SPARC64)
	select PAX_USERCOPY if ((X86 || SPARC || PPC || ARM) && (SLAB || SLUB || SLOB))

	help
	  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 1001.  With this option, 
	  the following features (in addition to those provided in the 
	  low additional security level) will be enabled:

	  - 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 reads/writes of /dev/kmem, /dev/mem, and /dev/port
	  - /proc restrictions with special GID set to 10 (usually wheel)
	  - Address Space Layout Randomization (ASLR)
	  - Prevent exploitation of most refcount overflows
	  - Bounds checking of copying between the kernel and userland

config GRKERNSEC_HIGH
	bool "High"
	select GRKERNSEC_LINK
	select GRKERNSEC_FIFO
	select GRKERNSEC_DMESG
	select GRKERNSEC_FORKFAIL
	select GRKERNSEC_TIME
	select GRKERNSEC_SIGNAL
	select GRKERNSEC_CHROOT
	select GRKERNSEC_CHROOT_SHMAT
	select GRKERNSEC_CHROOT_UNIX
	select GRKERNSEC_CHROOT_MOUNT
	select GRKERNSEC_CHROOT_FCHDIR
	select GRKERNSEC_CHROOT_PIVOT
	select GRKERNSEC_CHROOT_DOUBLE
	select GRKERNSEC_CHROOT_CHDIR
	select GRKERNSEC_CHROOT_MKNOD
	select GRKERNSEC_CHROOT_CAPS
	select GRKERNSEC_CHROOT_SYSCTL
	select GRKERNSEC_CHROOT_FINDTASK
	select GRKERNSEC_SYSFS_RESTRICT
	select GRKERNSEC_PROC
	select GRKERNSEC_PROC_MEMMAP if (PAX_NOEXEC || PAX_ASLR)
	select GRKERNSEC_HIDESYM
	select GRKERNSEC_BRUTE
	select GRKERNSEC_PROC_USERGROUP
	select GRKERNSEC_KMEM
	select GRKERNSEC_RESLOG
	select GRKERNSEC_RANDNET
	select GRKERNSEC_PROC_ADD
	select GRKERNSEC_CHROOT_CHMOD
	select GRKERNSEC_CHROOT_NICE
	select GRKERNSEC_AUDIT_MOUNT
	select GRKERNSEC_MODHARDEN if (MODULES)
	select GRKERNSEC_HARDEN_PTRACE
	select GRKERNSEC_VM86 if (X86_32)
	select GRKERNSEC_KERN_LOCKOUT if (X86 || ARM || PPC || SPARC)
	select PAX
	select PAX_RANDUSTACK
	select PAX_ASLR
	select PAX_RANDMMAP
	select PAX_NOEXEC
	select PAX_MPROTECT
	select PAX_EI_PAX
	select PAX_PT_PAX_FLAGS
	select PAX_HAVE_ACL_FLAGS
	select PAX_KERNEXEC if ((PPC || X86) && (!X86_32 || X86_WP_WORKS_OK) && !XEN)
	select PAX_MEMORY_UDEREF if (X86 && !XEN)
	select PAX_RANDKSTACK if (X86_TSC && X86)
	select PAX_SEGMEXEC if (X86_32)
	select PAX_PAGEEXEC
	select PAX_EMUPLT if (ALPHA || PARISC || SPARC)
	select PAX_EMUTRAMP if (PARISC)
	select PAX_EMUSIGRT if (PARISC)
	select PAX_ETEXECRELOCS if (ALPHA || IA64 || PARISC)
	select PAX_ELFRELOCS if (PAX_ETEXECRELOCS || (IA64 || PPC || X86))
	select PAX_REFCOUNT if (X86 || SPARC64)
	select PAX_USERCOPY if ((X86 || PPC || SPARC || ARM) && (SLAB || SLUB || SLOB))
	help
	  If you say Y here, many of the features of grsecurity will be
	  enabled, which 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 gid 1001.  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 of processes outside of chroot
	  - Capability restrictions in chroot
	  - Deny fchdir out of chroot
	  - Priority restrictions in chroot
	  - Segmentation-based implementation of PaX
	  - Mprotect restrictions
	  - Removal of addresses from /proc/<pid>/[smaps|maps|stat]
	  - Kernel stack randomization
	  - Mount/unmount/remount logging
	  - Kernel symbol hiding
	  - Hardening of module auto-loading
	  - Ptrace restrictions
	  - Restricted vm86 mode
	  - Restricted sysfs/debugfs
	  - Active kernel exploit response

config GRKERNSEC_CUSTOM
	bool "Custom"
	help
	  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.

endchoice

menu "Address Space Protection"
depends on GRKERNSEC

config GRKERNSEC_KMEM
	bool "Deny reading/writing to /dev/kmem, /dev/mem, and /dev/port"
	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. 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.

config GRKERNSEC_VM86
	bool "Restrict VM86 mode"
	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"
	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.  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.

config GRKERNSEC_PROC_MEMMAP
	bool "Remove addresses from /proc/<pid>/[smaps|maps|stat]"
	default y if (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.
	  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.

config GRKERNSEC_BRUTE
	bool "Deter exploit bruteforcing"
	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
	  processes terminated, and they are prevented from executing any further
	  processes 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"
	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"
	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.

config GRKERNSEC_KERN_LOCKOUT
	bool "Active kernel exploit response"
	depends on X86 || ARM || PPC || SPARC
	help
	  If you say Y here, when a PaX alert is triggered due to suspicious
	  activity in the kernel (from KERNEXEC/UDEREF/USERCOPY)
	  or an OOPs occurs due to bad memory accesses, instead of just
	  terminating the offending process (and potentially allowing
	  a subsequent exploit from the same user), we will take one of two
	  actions:
	   If the user was root, we will panic the system
	   If the user was non-root, we will log the attempt, terminate
	   all processes owned by the user, then prevent them from creating
	   any new processes until the system is restarted
	  This deters repeated kernel exploitation/bruteforcing attempts
	  and is useful for later forensics.

endmenu
menu "Role Based Access Control Options"
depends on GRKERNSEC

config GRKERNSEC_RBAC_DEBUG
	bool

config GRKERNSEC_NO_RBAC
	bool "Disable RBAC system"
	help
	  If you say Y here, the /dev/grsec device will be removed from the kernel,
	  preventing the RBAC system from being enabled.  You should only say Y
	  here if you have no intention of using the RBAC system, so as to prevent
	  an attacker with root access from misusing the RBAC system to hide files
	  and processes when loadable module support and /dev/[k]mem have been
	  locked down.

config GRKERNSEC_ACL_HIDEKERN
	bool "Hide kernel processes"
	help
	  If you say Y here, all kernel threads will be hidden to all
	  processes but those whose subject has the "view hidden processes"
	  flag.

config GRKERNSEC_ACL_MAXTRIES
	int "Maximum tries before password lockout"
	default 3
	help
	  This option enforces the maximum number of times a user can attempt
	  to authorize themselves with the grsecurity RBAC system before being
	  denied the ability to attempt authorization again for a specified time.
	  The lower the number, the harder it will be to brute-force a password.

config GRKERNSEC_ACL_TIMEOUT
	int "Time to wait after max password tries, in seconds"
	default 30
	help
	  This option specifies the time the user must wait after attempting to
	  authorize to the RBAC system with the maximum number of invalid
	  passwords.  The higher the number, the harder it will be to brute-force
	  a password.

endmenu
menu "Filesystem Protections"
depends on GRKERNSEC

config GRKERNSEC_PROC
	bool "Proc restrictions"
	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 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"
	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.

config GRKERNSEC_PROC_GID
	int "GID for special group"
	depends on GRKERNSEC_PROC_USERGROUP
	default 1001

config GRKERNSEC_PROC_ADD
	bool "Additional restrictions"
	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"
	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_FIFO
	bool "FIFO restrictions"
	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"
	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 only
	  be accessible 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.
	  This option is equivalent to a chmod 0700 of the mount paths.

config GRKERNSEC_ROFS
	bool "Runtime read-only mount protection"
	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.  This feature is mainly intended for secure embedded systems.

config GRKERNSEC_CHROOT
	bool "Chroot jail restrictions"
	help
	  If you say Y here, you will be able to choose several options that will
	  make breaking out of a chrooted jail much more difficult.  If you
	  encounter no software incompatibilities with the following options, it
	  is recommended that you enable each one.

config GRKERNSEC_CHROOT_MOUNT
	bool "Deny mounts"
	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"
	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"
	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"
	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"
	depends on GRKERNSEC_CHROOT
	help
	  If you say Y here, processes inside a chroot will not be able to chmod
	  or fchmod files to make them have suid or sgid bits.  This protects
	  against another published method of breaking a chroot.  If the sysctl
	  option is enabled, a sysctl option with name "chroot_deny_chmod" is
	  created.

config GRKERNSEC_CHROOT_FCHDIR
	bool "Deny fchdir out of chroot"
	depends on GRKERNSEC_CHROOT
	help
	  If you say Y here, a well-known method of breaking chroots by fchdir'ing
	  to a file descriptor of the chrooting process that points to a directory
	  outside the filesystem will be stopped.  If the sysctl option
	  is enabled, a sysctl option with name "chroot_deny_fchdir" is created.

config GRKERNSEC_CHROOT_MKNOD
	bool "Deny mknod"
	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"
	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"
	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"
	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"
	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"
	depends on GRKERNSEC_CHROOT
	help
	  If you say Y here, an attacker in a chroot will not be able to
	  write to sysctl entries, either by sysctl(2) or through a /proc
	  interface.  It is strongly recommended that you say Y here. If the
	  sysctl option is enabled, a sysctl option with name
	  "chroot_deny_sysctl" is created.

config GRKERNSEC_CHROOT_CAPS
	bool "Capability restrictions"
	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.

endmenu
menu "Kernel Auditing"
depends on GRKERNSEC

config GRKERNSEC_AUDIT_GROUP
	bool "Single group for auditing"
	help
	  If you say Y here, the exec, chdir, and (un)mount 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"
	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"
	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"
	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"
	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'
	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.  If the sysctl option is
	  enabled, a sysctl option with name "rwxmap_logging" is created.

config GRKERNSEC_AUDIT_TEXTREL
	bool 'ELF text relocations logging (READ HELP)'
	depends on PAX_MPROTECT
	help
	  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.

endmenu

menu "Executable Protections"
depends on GRKERNSEC

config GRKERNSEC_DMESG
	bool "Dmesg(8) restriction"
	help
	  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.
	  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"
	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_TPE
	bool "Trusted Path Execution (TPE)"
	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 "GID for 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_GID
	int "GID for trusted users"
	depends on GRKERNSEC_TPE && GRKERNSEC_TPE_INVERT
	default 1005
	help
	  Setting this GID determines what group TPE restrictions will be
	  *disabled* for.  If the sysctl option is enabled, a sysctl option
	  with name "tpe_gid" is created.

endmenu
menu "Network Protections"
depends on GRKERNSEC

config GRKERNSEC_RANDNET
	bool "Larger entropy pools"
	help
	  If you say Y here, the entropy pools used for many features of Linux
	  and grsecurity will be doubled in size.  Since several grsecurity
	  features use additional randomness, it is recommended that you say Y
	  here.  Saying Y here has a similar effect as modifying
	  /proc/sys/kernel/random/poolsize.

config GRKERNSEC_BLACKHOLE
	bool "TCP/UDP blackhole and LAST_ACK DoS prevention"
	depends on NET
	help
	  If you say Y here, neither TCP resets nor ICMP
	  destination-unreachable packets will be sent in response to packets
	  sent to ports for which no associated listening process exists.
	  This feature supports both IPV4 and IPV6 and exempts the 
	  loopback interface from blackholing.  Enabling this feature 
	  makes a host more resilient to DoS attacks and reduces network
	  visibility against scanners.

	  The blackhole feature as-implemented is equivalent to the FreeBSD
	  blackhole feature, as it prevents RST responses to all packets, not
	  just SYNs.  Under most application behavior this causes no
	  problems, but applications (like haproxy) may not close certain
	  connections in a way that cleanly terminates them on the remote
	  end, leaving the remote host in LAST_ACK state.  Because of this
	  side-effect and to prevent intentional LAST_ACK DoSes, this
	  feature also adds automatic mitigation against such attacks.
	  The mitigation drastically reduces the amount of time a socket
	  can spend in LAST_ACK state.  If you're using haproxy and not
	  all servers it connects to have this option enabled, consider
	  disabling this feature on the haproxy host.

	  If the sysctl option is enabled, two sysctl options with names
	  "ip_blackhole" and "lastack_retries" will be created.
	  While "ip_blackhole" takes the standard zero/non-zero on/off
	  toggle, "lastack_retries" uses the same kinds of values as
	  "tcp_retries1" and "tcp_retries2".  The default value of 4
	  prevents a socket from lasting more than 45 seconds in LAST_ACK
	  state.

config GRKERNSEC_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 "Sysctl support"
depends on GRKERNSEC && SYSCTL

config GRKERNSEC_SYSCTL
	bool "Sysctl support"
	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"
	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.

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.

endmenu

endmenu
