1  #### ⚠ This page is just for your information and inspiration.
   2  
   3  Grsecurity
   4  ----------
   5  
   6  `GRKERNSEC`\
   7  
   8      If you say Y here, you will be able to configure many features
   9      that will enhance the security of your system.  It is highly
  10      recommended that you say Y here and read through the help
  11      for each option so that you fully understand the features and
  12      can evaluate their usefulness for your machine.
  13  
  14  Configuration Method
  15  --------------------
  16  
  17      Choose between automatic or custom configuration here.
  18  
  19  ### Automatic
  20  
  21  `GRKERNSEC_CONFIG_AUTO`\
  22  
  23      If you choose this configuration method, you'll be able to answer a small
  24      number of simple questions about how you plan to use this kernel.
  25      The settings of grsecurity and PaX will be automatically configured for
  26      the highest commonly-used settings within the provided constraints.
  27  
  28      If you require additional configuration, custom changes can still be made
  29      from the "custom configuration" menu.
  30  
  31  ### Custom
  32  
  33  `GRKERNSEC_CONFIG_CUSTOM`\
  34  
  35      If you choose this configuration method, you'll be able to configure all
  36      grsecurity and PaX settings manually.  Via this method, no options are
  37      automatically enabled.
  38  
  39      Take note that if menuconfig is exited with this configuration method
  40      chosen, you will not be able to use the automatic configuration methods
  41      without starting again with a kernel configuration with no grsecurity
  42      or PaX options specified inside.
  43  
  44  Usage Type
  45  ----------
  46  
  47      Choose between server or desktop here.
  48  
  49  ### Server
  50  
  51  `GRKERNSEC_CONFIG_SERVER`\
  52  
  53      Choose this option if you plan to use this kernel on a server.
  54  
  55  ### Desktop
  56  
  57  `GRKERNSEC_CONFIG_DESKTOP`\
  58  
  59      Choose this option if you plan to use this kernel on a desktop.
  60  
  61  Virtualization Type
  62  -------------------
  63  
  64      Choose between no, guest, or host virtualization here.
  65  
  66  ### None
  67  
  68  `GRKERNSEC_CONFIG_VIRT_NONE`\
  69  
  70      Choose this option if this kernel will be run on bare metal.
  71  
  72  ### Guest
  73  
  74  `GRKERNSEC_CONFIG_VIRT_GUEST`\
  75  
  76      Choose this option if this kernel will be run as a VM guest.
  77  
  78  ### Host
  79  
  80  `GRKERNSEC_CONFIG_VIRT_HOST`\
  81  
  82      Choose this option if this kernel will be run as a VM host.
  83  
  84  Virtualization Hardware
  85  -----------------------
  86  
  87      Choose between no or EPT/RVI hardware virtualization support here.
  88  
  89  ### EPT/RVI Processor Support
  90  
  91  `GRKERNSEC_CONFIG_VIRT_EPT`\
  92  
  93      Choose this option if your CPU supports the EPT or RVI features of 2nd-gen
  94      hardware virtualization.  This allows for additional kernel hardening protections
  95      to operate without additional performance impact.
  96  
  97      To see if your Intel processor supports EPT, see:
  98      http://ark.intel.com/Products/VirtualizationTechnology
  99      (Most Core i3/5/7 support EPT)
 100  
 101      To see if your AMD processor supports RVI, see:
 102      http://support.amd.com/us/kbarticles/Pages/GPU120AMDRVICPUsHyperVWin8.aspx
 103  
 104  ### First-gen/No Hardware Virtualization
 105  
 106  `GRKERNSEC_CONFIG_VIRT_SOFT`\
 107  
 108      Choose this option if you use an Atom/Pentium/Core 2 processor that either doesn't
 109      support hardware virtualization or doesn't support the EPT/RVI extensions.
 110  
 111  Virtualization Software
 112  -----------------------
 113  
 114      Choose between Xen, Xen PV, VMware, KVM, VirtualBox, or HyperV virtualization here.
 115  
 116  ### Paravirtualized Xen
 117  
 118  `GRKERNSEC_CONFIG_VIRT_XEN_PV`\
 119  
 120      Choose this option if this kernel is running as a Paravirtualized Xen domU or dom0.
 121      KERNEXEC on both i386 and x86_64 and UDEREF on x86_64, as well as RANDKSTACK will
 122      not be enabled.
 123  
 124  ### PVHVM/HVM Xen
 125  
 126  `GRKERNSEC_CONFIG_VIRT_XEN`\
 127  
 128      Choose this option if this kernel is running as a non-PV Xen domU or dom0.
 129  
 130  ### VMWare
 131  
 132  `GRKERNSEC_CONFIG_VIRT_VMWARE`\
 133  
 134      Choose this option if this kernel is running as a VMWare guest or host.
 135  
 136  ### KVM
 137  
 138  `GRKERNSEC_CONFIG_VIRT_KVM`\
 139  
 140      Choose this option if this kernel is running as a KVM guest or host.
 141  
 142  ### VirtualBox
 143  
 144  `GRKERNSEC_CONFIG_VIRT_VIRTUALBOX`\
 145  
 146      Choose this option if this kernel is running as a VirtualBox guest or host.
 147  
 148  ### Hyper-V
 149  
 150  `GRKERNSEC_CONFIG_VIRT_HYPERV`\
 151  
 152      Choose this option if this kernel is running as a Hyper-V guest.
 153  
 154  Required Priorities
 155  -------------------
 156  
 157      Choose between performance or security priorities here.
 158  
 159  ### Performance
 160  
 161  `GRKERNSEC_CONFIG_PRIORITY_PERF`\
 162  
 163      Choose this option if performance is of highest priority for this deployment
 164      of grsecurity.  Features like kernel stack clearing, clearing of structures
 165      intended for userland, and freed memory sanitizing will be disabled.
 166  
 167  ### Security
 168  
 169  `GRKERNSEC_CONFIG_PRIORITY_SECURITY`\
 170  
 171      Choose this option if security is of highest priority for this deployment of
 172      grsecurity.  Kernel stack clearing, clearing of structures intended for
 173      userland, and freed memory sanitizing will be enabled for this kernel.
 174      In a worst-case scenario, these features can introduce a 10% performance hit.
 175  
 176  Default Special Groups
 177  ----------------------
 178  
 179  ### GID exempted from /proc restrictions
 180  
 181  `GRKERNSEC_PROC_GID`\
 182  
 183      Setting this GID determines which group will be exempted from
 184      grsecurity's /proc restrictions, allowing users of the specified
 185      group  to view network statistics and the existence of other users'
 186      processes on the system.  This GID may also be chosen at boot time
 187      via "grsec_proc_gid=" on the kernel commandline.
 188  
 189  ### GID for TPE-untrusted users
 190  
 191  `GRKERNSEC_TPE_UNTRUSTED_GID`\
 192  
 193      Setting this GID determines what group TPE restrictions will be
 194      *enabled* for.  If the sysctl option is enabled, a sysctl option
 195      with name "tpe_gid" is created.
 196  
 197  ### GID for TPE-trusted users
 198  
 199  `GRKERNSEC_TPE_TRUSTED_GID`\
 200  
 201      Setting this GID determines what group TPE restrictions will be
 202      *disabled* for.  If the sysctl option is enabled, a sysctl option
 203      with name "tpe_gid" is created.
 204  
 205  ### GID for users with kernel-enforced SymlinksIfOwnerMatch
 206  
 207  `GRKERNSEC_SYMLINKOWN_GID`\
 208  
 209      Setting this GID determines what group kernel-enforced
 210      SymlinksIfOwnerMatch will be enabled for.  If the sysctl option
 211      is enabled, a sysctl option with name "symlinkown_gid" is created.
 212  
 213  Customize Configuration
 214  -----------------------
 215  
 216  ### PaX
 217  
 218  #### Enable various PaX features
 219  
 220  `PAX`\
 221  
 222      This allows you to enable various PaX features.  PaX adds
 223      intrusion prevention mechanisms to the kernel that reduce
 224      the risks posed by exploitable memory corruption bugs.
 225  
 226  #### PaX Control
 227  
 228  ##### Support soft mode
 229  
 230  `PAX_SOFTMODE`\
 231  
 232      Enabling this option will allow you to run PaX in soft mode, that
 233      is, PaX features will not be enforced by default, only on executables
 234      marked explicitly.  You must also enable PT_PAX_FLAGS or XATTR_PAX_FLAGS
 235      support as they are the only way to mark executables for soft mode use.
 236  
 237      Soft mode can be activated by using the "pax_softmode=1" kernel command
 238      line option on boot.  Furthermore you can control various PaX features
 239      at runtime via the entries in /proc/sys/kernel/pax.
 240  
 241  ##### Use legacy ELF header marking
 242  
 243  `PAX_EI_PAX`\
 244  
 245      Enabling this option will allow you to control PaX features on
 246      a per executable basis via the 'chpax' utility available at
 247      http://pax.grsecurity.net/.  The control flags will be read from
 248      an otherwise reserved part of the ELF header.  This marking has
 249      numerous drawbacks (no support for soft-mode, toolchain does not
 250      know about the non-standard use of the ELF header) therefore it
 251      has been deprecated in favour of PT_PAX_FLAGS and XATTR_PAX_FLAGS
 252      support.
 253  
 254      Note that if you enable PT_PAX_FLAGS or XATTR_PAX_FLAGS marking
 255      support as well, they will override the legacy EI_PAX marks.
 256  
 257      If you enable none of the marking options then all applications
 258      will run with PaX enabled on them by default.
 259  
 260  ##### Use ELF program header marking
 261  
 262  `PAX_PT_PAX_FLAGS`\
 263  
 264      Enabling this option will allow you to control PaX features on
 265      a per executable basis via the 'paxctl' utility available at
 266      http://pax.grsecurity.net/.  The control flags will be read from
 267      a PaX specific ELF program header (PT_PAX_FLAGS).  This marking
 268      has the benefits of supporting both soft mode and being fully
 269      integrated into the toolchain (the binutils patch is available
 270      from http://pax.grsecurity.net).
 271  
 272      Note that if you enable the legacy EI_PAX marking support as well,
 273      the EI_PAX marks will be overridden by the PT_PAX_FLAGS marks.
 274  
 275      If you enable both PT_PAX_FLAGS and XATTR_PAX_FLAGS support then you
 276      must make sure that the marks are the same if a binary has both marks.
 277  
 278      If you enable none of the marking options then all applications
 279      will run with PaX enabled on them by default.
 280  
 281  ##### Use filesystem extended attributes marking
 282  
 283  `PAX_XATTR_PAX_FLAGS`\
 284  
 285      Enabling this option will allow you to control PaX features on
 286      a per executable basis via the 'setfattr' utility.  The control
 287      flags will be read from the user.pax.flags extended attribute of
 288      the file.  This marking has the benefit of supporting binary-only
 289      applications that self-check themselves (e.g., skype) and would
 290      not tolerate chpax/paxctl changes.  The main drawback is that
 291      extended attributes are not supported by some filesystems (e.g.,
 292      isofs, udf, vfat) so copying files through such filesystems will
 293      lose the extended attributes and these PaX markings.
 294  
 295      Note that if you enable the legacy EI_PAX marking support as well,
 296      the EI_PAX marks will be overridden by the XATTR_PAX_FLAGS marks.
 297  
 298      If you enable both PT_PAX_FLAGS and XATTR_PAX_FLAGS support then you
 299      must make sure that the marks are the same if a binary has both marks.
 300  
 301      If you enable none of the marking options then all applications
 302      will run with PaX enabled on them by default.
 303  
 304  ##### MAC system integration
 305  
 306      Mandatory Access Control systems have the option of controlling
 307      PaX flags on a per executable basis, choose the method supported
 308      by your particular system.
 309  
 310      - "none": if your MAC system does not interact with PaX,
 311      - "direct": if your MAC system defines pax_set_initial_flags() itself,
 312      - "hook": if your MAC system uses the pax_set_initial_flags_func callback.
 313  
 314      NOTE: this option is for developers/integrators only.
 315  
 316  ###### none
 317  
 318  `PAX_NO_ACL_FLAGS`\
 319  
 320  ###### direct
 321  
 322  `PAX_HAVE_ACL_FLAGS`\
 323  
 324  ###### hook
 325  
 326  `PAX_HOOK_ACL_FLAGS`\
 327  
 328  #### Non-executable pages
 329  
 330  ##### Enforce non-executable pages
 331  
 332  `PAX_NOEXEC`\
 333  
 334      By design some architectures do not allow for protecting memory
 335      pages against execution or even if they do, Linux does not make
 336      use of this feature.  In practice this means that if a page is
 337      readable (such as the stack or heap) it is also executable.
 338  
 339      There is a well known exploit technique that makes use of this
 340      fact and a common programming mistake where an attacker can
 341      introduce code of his choice somewhere in the attacked program's
 342      memory (typically the stack or the heap) and then execute it.
 343  
 344      If the attacked program was running with different (typically
 345      higher) privileges than that of the attacker, then he can elevate
 346      his own privilege level (e.g. get a root shell, write to files for
 347      which he does not have write access to, etc).
 348  
 349      Enabling this option will let you choose from various features
 350      that prevent the injection and execution of 'foreign' code in
 351      a program.
 352  
 353      This will also break programs that rely on the old behaviour and
 354      expect that dynamically allocated memory via the malloc() family
 355      of functions is executable (which it is not).  Notable examples
 356      are the XFree86 4.x server, the java runtime and wine.
 357  
 358  ##### Paging based non-executable pages
 359  
 360  `PAX_PAGEEXEC`\
 361  
 362      This implementation is based on the paging feature of the CPU.
 363  
 364      On alpha, avr32, ia64, parisc, sparc, sparc64, x86_64 and i386
 365      with hardware non-executable bit support there is no performance
 366      impact, on ppc the impact is negligible.
 367  
 368      Note that several architectures require various emulations due to
 369      badly designed userland ABIs, this will cause a performance impact
 370      but will disappear as soon as userland is fixed.  For example, ppc
 371      userland MUST have been built with secure-plt by a recent toolchain.
 372  
 373  ##### Segmentation based non-executable pages
 374  
 375  `PAX_SEGMEXEC`\
 376  
 377      This implementation is based on the segmentation feature of the
 378      CPU and has a very small performance impact, however applications
 379      will be limited to a 1.5 GB address space instead of the normal
 380      3 GB.
 381  
 382  ##### Emulate trampolines
 383  
 384  `PAX_EMUTRAMP`\
 385  
 386      There are some programs and libraries that for one reason or
 387      another attempt to execute special small code snippets from
 388      non-executable memory pages.  Most notable examples are the
 389      signal handler return code generated by the kernel itself and
 390      the GCC trampolines.
 391  
 392      If you enabled CONFIG_PAX_PAGEEXEC or CONFIG_PAX_SEGMEXEC then
 393      such programs will no longer work under your kernel.
 394  
 395      As a remedy you can say Y here and use the 'chpax' or 'paxctl'
 396      utilities to enable trampoline emulation for the affected programs
 397      yet still have the protection provided by the non-executable pages.
 398  
 399      On parisc you MUST enable this option and EMUSIGRT as well, otherwise
 400      your system will not even boot.
 401  
 402      Alternatively you can say N here and use the 'chpax' or 'paxctl'
 403      utilities to disable CONFIG_PAX_PAGEEXEC and CONFIG_PAX_SEGMEXEC
 404      for the affected files.
 405  
 406      NOTE: enabling this feature *may* open up a loophole in the
 407      protection provided by non-executable pages that an attacker
 408      could abuse.  Therefore the best solution is to not have any
 409      files on your system that would require this option.  This can
 410      be achieved by not using libc5 (which relies on the kernel
 411      signal handler return code) and not using or rewriting programs
 412      that make use of the nested function implementation of GCC.
 413      Skilled users can just fix GCC itself so that it implements
 414      nested function calls in a way that does not interfere with PaX.
 415  
 416  ##### Automatically emulate sigreturn trampolines
 417  
 418  `PAX_EMUSIGRT`\
 419  
 420      Enabling this option will have the kernel automatically detect
 421      and emulate signal return trampolines executing on the stack
 422      that would otherwise lead to task termination.
 423  
 424      This solution is intended as a temporary one for users with
 425      legacy versions of libc (libc5, glibc 2.0, uClibc before 0.9.17,
 426      Modula-3 runtime, etc) or executables linked to such, basically
 427      everything that does not specify its own SA_RESTORER function in
 428      normal executable memory like glibc 2.1+ does.
 429  
 430      On parisc you MUST enable this option, otherwise your system will
 431      not even boot.
 432  
 433      NOTE: this feature cannot be disabled on a per executable basis
 434      and since it *does* open up a loophole in the protection provided
 435      by non-executable pages, the best solution is to not have any
 436      files on your system that would require this option.
 437  
 438  ##### Restrict mprotect()
 439  
 440  `PAX_MPROTECT`\
 441  
 442      Enabling this option will prevent programs from
 443       - changing the executable status of memory pages that were
 444         not originally created as executable,
 445       - making read-only executable pages writable again,
 446       - creating executable pages from anonymous memory,
 447       - making read-only-after-relocations (RELRO) data pages writable again.
 448  
 449      You should say Y here to complete the protection provided by
 450      the enforcement of non-executable pages.
 451  
 452      NOTE: you can use the 'chpax' or 'paxctl' utilities to control
 453      this feature on a per file basis.
 454  
 455  ##### Use legacy/compat protection demoting (read help)
 456  
 457  `PAX_MPROTECT_COMPAT`\
 458  
 459      The current implementation of PAX_MPROTECT denies RWX allocations/mprotects
 460      by sending the proper error code to the application.  For some older
 461      userland, this can cause problems with applications that assume such
 462      allocations will not be prevented by PaX or SELinux and other access
 463      control systems and have no fallback mechanisms.  For modern distros,
 464      this option should generally be set to 'N'.
 465  
 466  ##### Allow ELF text relocations (read help)
 467  
 468  `PAX_ELFRELOCS`\
 469  
 470      Non-executable pages and mprotect() restrictions are effective
 471      in preventing the introduction of new executable code into an
 472      attacked task's address space.  There remain only two venues
 473      for this kind of attack: if the attacker can execute already
 474      existing code in the attacked task then he can either have it
 475      create and mmap() a file containing his code or have it mmap()
 476      an already existing ELF library that does not have position
 477      independent code in it and use mprotect() on it to make it
 478      writable and copy his code there.  While protecting against
 479      the former approach is beyond PaX, the latter can be prevented
 480      by having only PIC ELF libraries on one's system (which do not
 481      need to relocate their code).  If you are sure this is your case,
 482      as is the case with all modern Linux distributions, then leave
 483      this option disabled.  You should say 'n' here.
 484  
 485  ##### Allow ELF ET\_EXEC text relocations
 486  
 487  `PAX_ETEXECRELOCS`\
 488  
 489      On some architectures there are incorrectly created applications
 490      that require text relocations and would not work without enabling
 491      this option.  If you are an alpha, ia64 or parisc user, you should
 492      enable this option and disable it once you have made sure that
 493      none of your applications need it.
 494  
 495  ##### Automatically emulate ELF PLT
 496  
 497  `PAX_EMUPLT`\
 498  
 499      Enabling this option will have the kernel automatically detect
 500      and emulate the Procedure Linkage Table entries in ELF files.
 501      On some architectures such entries are in writable memory, and
 502      become non-executable leading to task termination.  Therefore
 503      it is mandatory that you enable this option on alpha, parisc,
 504      sparc and sparc64, otherwise your system would not even boot.
 505  
 506      NOTE: this feature *does* open up a loophole in the protection
 507      provided by the non-executable pages, therefore the proper
 508      solution is to modify the toolchain to produce a PLT that does
 509      not need to be writable.
 510  
 511  ##### Emulate old glibc resolver stub
 512  
 513  `PAX_DLRESOLVE`\
 514  
 515      This option is needed if userland has an old glibc (before 2.4)
 516      that puts a 'save' instruction into the runtime generated resolver
 517      stub that needs special emulation.
 518  
 519  ##### Enforce non-executable kernel pages
 520  
 521  `PAX_KERNEXEC`\
 522  
 523      This is the kernel land equivalent of PAGEEXEC and MPROTECT,
 524      that is, enabling this option will make it harder to inject
 525      and execute 'foreign' code in kernel memory itself.
 526  
 527      Note that on amd64, CONFIG_EFI enabled with "efi=old_map" on
 528      the kernel command-line will result in an RWX physical map.
 529  
 530      Likewise, the EFI runtime services are necessarily mapped as
 531      RWX.  If CONFIG_EFI is enabled on an EFI-capable system, it
 532      is recommended that you boot with "noefi" on the kernel
 533      command-line if possible to eliminate the mapping.
 534  
 535  ##### Code Pointer Instrumentation Method
 536  
 537      KERNEXEC on amd64 is not as secure as its i386 variant due to the
 538      lack of certain processor features.  This option can bring back some
 539      of the security by forcing all code pointers at runtime to fall into
 540      kernel memory.  This is achieved via compile time instrumentation of
 541      all code pointer dereferences (indirect calls and function returns).
 542  
 543      While there are alternative mechanisms (SMEP, UDEREF) that can achieve
 544      the same or even more, they also have their own drawbacks in terms of
 545      performance impact and/or being processor dependent so this feature
 546      offers a choice by having a low performance impact and being processor
 547      independent.
 548  
 549      If you enabled RAP (see PAX_RAP) and have an amd64 processor that does
 550      not support SMEP then you must also enable a KERNEXEC code pointer
 551      instrumentation method.
 552  
 553      Note that binary modules cannot be instrumented by this approach.
 554  
 555      Note that the implementation requires a gcc with plugin support,
 556      i.e., gcc 4.5 or newer.  You may need to install the supporting
 557      headers explicitly in addition to the normal gcc package.
 558  
 559  ###### none
 560  
 561  `PAX_KERNEXEC_PLUGIN_METHOD_NONE`\
 562  
 563      In case your processor supports Supervisor Mode Execution
 564      Prevention (SMEP) you should choose this option to disable
 565      compile time instrumentation.
 566  
 567      Note that the kernel will refuse to boot if SMEP is not
 568      supported by the processor or is disabled on the kernel
 569      command line.
 570  
 571  ###### bts
 572  
 573  `PAX_KERNEXEC_PLUGIN_METHOD_BTS`\
 574  
 575      This method is compatible with binary only modules but has
 576      a higher runtime overhead.
 577  
 578  ##### Minimum amount of memory reserved for module code
 579  
 580  `PAX_KERNEXEC_MODULE_TEXT`\
 581  
 582      Due to implementation details the kernel must reserve a fixed
 583      amount of memory for runtime allocated code (such as modules)
 584      at compile time that cannot be changed at runtime.  Here you
 585      can specify the minimum amount in MB that will be reserved.
 586      Due to the same implementation details this size will always
 587      be rounded up to the next 2/4 MB boundary (depends on PAE) so
 588      the actually available memory for runtime allocated code will
 589      usually be more than this minimum.
 590  
 591      The default 4 MB should be enough for most users but if you have
 592      an excessive number of modules (e.g., most distribution configs
 593      compile many drivers as modules) or use huge modules such as
 594      nvidia's kernel driver, you will need to adjust this amount.
 595      A good rule of thumb is to look at your currently loaded kernel
 596      modules and add up their sizes.
 597  
 598  #### Address Space Layout Randomization
 599  
 600  ##### Address Space Layout Randomization
 601  
 602  `PAX_ASLR`\
 603  
 604      Many if not most exploit techniques rely on the knowledge of
 605      certain addresses in the attacked program.  The following options
 606      will allow the kernel to apply a certain amount of randomization
 607      to specific parts of the program thereby forcing an attacker to
 608      guess them in most cases.  Any failed guess will most likely crash
 609      the attacked program which allows the kernel to detect such attempts
 610      and react on them.  PaX itself provides no reaction mechanisms,
 611      instead it is strongly encouraged that you make use of grsecurity's
 612      (http://www.grsecurity.net/) built-in crash detection features or
 613      develop one yourself.
 614  
 615      By saying Y here you can choose to randomize the following areas:
 616       - top of the task's kernel stack
 617       - top of the task's userland stack
 618       - base address for mmap() requests that do not specify one
 619         (this includes all libraries)
 620       - base address of the main executable
 621  
 622      It is strongly recommended to say Y here as address space layout
 623      randomization has negligible impact on performance yet it provides
 624      a very effective protection.
 625  
 626      NOTE: you can use the 'chpax' or 'paxctl' utilities to control
 627      this feature on a per file basis.
 628  
 629  ##### Randomize kernel stack base
 630  
 631  `PAX_RANDKSTACK`\
 632  
 633      By saying Y here the kernel will randomize every task's kernel
 634      stack on every system call.  This will not only force an attacker
 635      to guess it but also prevent him from making use of possible
 636      leaked information about it.
 637  
 638      Since the kernel stack is a rather scarce resource, randomization
 639      may cause unexpected stack overflows, therefore you should very
 640      carefully test your system.  Note that once enabled in the kernel
 641      configuration, this feature cannot be disabled on a per file basis.
 642  
 643  ##### Randomize user stack and mmap() bases
 644  
 645  `PAX_RANDMMAP`\
 646  
 647      By saying Y here the kernel will randomize every task's userland
 648      stack and use a randomized base address for mmap() requests that
 649      do not specify one themselves.
 650  
 651      The stack randomization is done in two steps where the second
 652      one may apply a big amount of shift to the top of the stack and
 653      cause problems for programs that want to use lots of memory (more
 654      than 2.5 GB if SEGMEXEC is not active, or 1.25 GB when it is).
 655  
 656      As a result of mmap randomization all dynamically loaded libraries
 657      will appear at random addresses and therefore be harder to exploit
 658      by a technique where an attacker attempts to execute library code
 659      for his purposes (e.g. spawn a shell from an exploited program that
 660      is running at an elevated privilege level).
 661  
 662      Furthermore, if a program is relinked as a dynamic ELF file, its
 663      base address will be randomized as well, completing the full
 664      randomization of the address space layout.  Attacking such programs
 665      becomes a guess game.  You can find an example of doing this at
 666      http://pax.grsecurity.net/et_dyn.tar.gz and practical samples at
 667      http://www.grsecurity.net/grsec-gcc-specs.tar.gz .
 668  
 669      NOTE: you can use the 'chpax' or 'paxctl' utilities to control this
 670      feature on a per file basis.
 671  
 672  #### Miscellaneous hardening features
 673  
 674  ##### Sanitize all freed memory
 675  
 676  `PAX_MEMORY_SANITIZE`\
 677  
 678      By saying Y here the kernel will erase memory pages and slab objects
 679      as soon as they are freed.  This in turn reduces the lifetime of data
 680      stored in them, making it less likely that sensitive information such
 681      as passwords, cryptographic secrets, etc stay in memory for too long.
 682  
 683      This is especially useful for programs whose runtime is short, long
 684      lived processes and the kernel itself benefit from this as long as
 685      they ensure timely freeing of memory that may hold sensitive
 686      information.
 687  
 688      A nice side effect of the sanitization of slab objects is the
 689      reduction of possible info leaks caused by padding bytes within the
 690      leaky structures.  Use-after-free bugs for structures containing
 691      pointers can also be detected as dereferencing the sanitized pointer
 692      will generate an access violation.
 693  
 694      The tradeoff is performance impact, on a single CPU system kernel
 695      compilation sees a 3% slowdown, other systems and workloads may vary
 696      and you are advised to test this feature on your expected workload
 697      before deploying it.
 698  
 699      The slab sanitization feature excludes a few slab caches per default
 700      for performance reasons.  To extend the feature to cover those as
 701      well, pass "pax_sanitize_slab=full" as kernel command line parameter.
 702  
 703      To reduce the performance penalty by sanitizing pages only, albeit
 704      limiting the effectiveness of this feature at the same time, slab
 705      sanitization can be disabled with the kernel command line parameter
 706      "pax_sanitize_slab=off".
 707  
 708      Note that this feature does not protect data stored in live pages,
 709      e.g., process memory swapped to disk may stay there for a long time.
 710  
 711  ##### Sanitize kernel stack
 712  
 713  `PAX_MEMORY_STACKLEAK`\
 714  
 715      By saying Y here the kernel will erase the kernel stack before it
 716      returns from a system call.  This in turn reduces the information
 717      that a kernel stack leak bug can reveal.
 718  
 719      Note that such a bug can still leak information that was put on
 720      the stack by the current system call (the one eventually triggering
 721      the bug) but traces of earlier system calls on the kernel stack
 722      cannot leak anymore.
 723  
 724      The tradeoff is performance impact: on a single CPU system kernel
 725      compilation sees a 1% slowdown, other systems and workloads may vary
 726      and you are advised to test this feature on your expected workload
 727      before deploying it.
 728  
 729      Note that the full feature requires a gcc with plugin support,
 730      i.e., gcc 4.5 or newer.  You may need to install the supporting
 731      headers explicitly in addition to the normal gcc package.  Using
 732      older gcc versions means that functions with large enough stack
 733      frames may leave uninitialized memory behind that may be exposed
 734      to a later syscall leaking the stack.
 735  
 736  ##### Forcibly initialize local variables copied to userland
 737  
 738  `PAX_MEMORY_STRUCTLEAK`\
 739  
 740      By saying Y here the kernel will zero initialize some local
 741      variables that are going to be copied to userland.  This in
 742      turn prevents unintended information leakage from the kernel
 743      stack should later code forget to explicitly set all parts of
 744      the copied variable.
 745  
 746      The tradeoff is less performance impact than PAX_MEMORY_STACKLEAK
 747      at a much smaller coverage.
 748  
 749      Note that the implementation requires a gcc with plugin support,
 750      i.e., gcc 4.5 or newer.  You may need to install the supporting
 751      headers explicitly in addition to the normal gcc package.
 752  
 753  ##### Prevent invalid userland pointer dereference
 754  
 755  `PAX_MEMORY_UDEREF`\
 756  
 757      By saying Y here the kernel will be prevented from dereferencing
 758      userland pointers in contexts where the kernel expects only kernel
 759      pointers.  This is both a useful runtime debugging feature and a
 760      security measure that prevents exploiting a class of kernel bugs.
 761  
 762      Another purpose of this feature is to prevent userland from accessing
 763      kernel memory during speculative execution (CVE-2017-5754, Meltdown).
 764      For best performance on i386 all userland should be recompiled with
 765      -mno-tls-direct-seg-refs and libc should be a 'nosegneg' variant.
 766  
 767      Note that when enabling this feature on guest kernels running on old
 768      CPUs without hardware virtualization support there may be a huge
 769      slowdown therefore you should not enable this feature for kernels
 770      meant to run in such environments.
 771  
 772      On X86_64 the kernel will make use of PCID support when available
 773      (Intel's Westmere, Sandy Bridge, etc).
 774  
 775  ##### Prevent various kernel object reference counter overflows
 776  
 777  `PAX_REFCOUNT`\
 778  
 779      By saying Y here the kernel will detect and prevent overflowing
 780      various (but not all) kinds of object reference counters.  Such
 781      overflows can normally occur due to bugs only and are often, if
 782      not always, exploitable.
 783  
 784      The tradeoff is that data structures protected by an overflowed
 785      refcount will never be freed and therefore will leak memory.  Note
 786      that this leak also happens even without this protection but in
 787      that case the overflow can eventually trigger the freeing of the
 788      data structure while it is still being used elsewhere, resulting
 789      in the exploitable situation that this feature prevents.
 790  
 791      Since this has a negligible performance impact, you should enable
 792      this feature.
 793  
 794  ##### Harden memory copies between kernel and userland
 795  
 796  `PAX_USERCOPY`\
 797  
 798      By saying Y here the kernel will enforce the size of heap objects
 799      when they are copied in either direction between the kernel and
 800      userland, even if only a part of the heap object is copied.
 801  
 802      Specifically, this checking prevents information leaking from the
 803      kernel heap during kernel to userland copies (if the kernel heap
 804      object is otherwise fully initialized) and prevents kernel heap
 805      overflows during userland to kernel copies.
 806  
 807      Note that the current implementation provides the strictest bounds
 808      checks for the SLUB allocator.
 809  
 810      Enabling this option also enables per-slab cache protection against
 811      data in a given cache being copied into/out of via userland
 812      accessors.  Though the whitelist of regions will be reduced over
 813      time, it notably protects important data structures like task structs.
 814  
 815      If frame pointers are enabled on x86, this option will also restrict
 816      copies into and out of the kernel stack to local variables within a
 817      single frame.
 818  
 819      Since this has a negligible performance impact, you should enable
 820      this feature.
 821  
 822  ##### Automatically constify eligible structures
 823  
 824  `PAX_CONSTIFY_PLUGIN`\
 825  
 826      By saying Y here the compiler will automatically constify a class
 827      of types that contain only function pointers.  This reduces the
 828      kernel's attack surface and also produces a better memory layout.
 829  
 830      Note that the implementation requires a gcc with plugin support,
 831      i.e., gcc 4.5 or newer.  You may need to install the supporting
 832      headers explicitly in addition to the normal gcc package.
 833  
 834      Note that if some code really has to modify constified variables
 835      then the source code will have to be patched to allow it.  Examples
 836      can be found in PaX itself (the no_const attribute) and for some
 837      out-of-tree modules at http://www.grsecurity.net/~paxguy1/ .
 838  
 839  ##### Report code regions instrumented for writing to constified data
 840  
 841  `PAX_CONSTIFY_PLUGIN_VERBOSE`\
 842  
 843      Print out the start and end of code regions that are enabled to
 844      modify otherwise read-only memory.
 845  
 846  ##### Prevent various integer overflows in function size parameters
 847  
 848  `PAX_SIZE_OVERFLOW`\
 849  
 850      By saying Y here the kernel recomputes expressions of function
 851      arguments marked by a size_overflow attribute with double integer
 852      precision (DImode/TImode for 32/64 bit integer types).
 853  
 854      If the recomputed argument does not fit the original type then the
 855      event is logged.  If the pax_size_overflow_report_only parameter is
 856      NOT passed on the kernel command line at boot then the triggering
 857      process will also be killed.  Alternatively, the pax_so_report_only
 858      parameter provides finer grained control over whether all events
 859      should cause the triggering process to be killed or only those that
 860      were not detected by the extra instrumentation (for more details
 861      see PAX_SIZE_OVERFLOW_EXTRA).
 862  
 863      Homepage: https://github.com/ephox-gcc-plugins/size_overflow
 864      Blog: http://forums.grsecurity.net/viewtopic.php?f=7&t=3043
 865  
 866      Note that the implementation requires a gcc with plugin support,
 867      i.e., gcc 4.5 or newer.  You may need to install the supporting
 868      headers explicitly in addition to the normal gcc package.
 869  
 870  ##### Increase coverage of size overflow checking
 871  
 872  `PAX_SIZE_OVERFLOW_EXTRA`\
 873  
 874      By saying Y here the kernel will instrument more size argument
 875      calculations that off-line static analysis tracked back through
 876      indirect function calls, structure fields and global variables.
 877  
 878      This greatly increases coverage and thus security however there
 879      are also more false positives and the performance impact is higher
 880      as well.
 881  
 882  ##### Log missing size overflow hash table entries
 883  
 884  `PAX_SIZE_OVERFLOW_HASHGEN`\
 885  
 886      By saying Y here the size overflow gcc plugin will perform data
 887      flow analysis during the kernel build process to detect new code
 888      that affects size calculations.  New discoveries are logged to
 889      to stderr for later integration into the size overflow plugin's
 890      metadata hash tables.  Unless you are developing this plugin or
 891      are otherwise interested in instrumenting new code, you should
 892      say N here.
 893  
 894  ##### Free more kernel memory after init
 895  
 896  `PAX_INITIFY`\
 897  
 898      The kernel has a mechanism to free up code and data memory that is
 899      only used during kernel or module initialization.  Enabling this
 900      feature will teach the compiler to find more such code and data
 901      that can be freed after initialization.
 902  
 903  ##### Free more kernel memory after init (verbose mode)
 904  
 905  `PAX_INITIFY_VERBOSE`\
 906  
 907      Print all initified strings and all functions which should be
 908      __init/__exit.
 909  
 910      Note that the candidates identified for __init/__exit markings
 911      depend on the current kernel configuration and thus should be
 912      verified manually before the source code is patched.
 913  
 914  ##### Generate some entropy during boot and runtime
 915  
 916  `PAX_LATENT_ENTROPY`\
 917  
 918      By saying Y here the kernel will instrument some kernel code to
 919      extract some entropy from both original and artificially created
 920      program state.  This will help especially embedded systems where
 921      there is little 'natural' source of entropy normally.  The cost
 922      is some slowdown of the boot process (about 0.5%) and fork and
 923      irq processing.
 924  
 925      When pax_extra_latent_entropy is passed on the kernel command line,
 926      entropy will be extracted from up to the first 4GB of RAM while the
 927      runtime memory allocator is being initialized.  This costs even more
 928      slowdown of the boot process.
 929  
 930      Note that the implementation requires a gcc with plugin support,
 931      i.e., gcc 4.5 or newer.  You may need to install the supporting
 932      headers explicitly in addition to the normal gcc package.
 933  
 934      Note that entropy extracted this way is not cryptographically
 935      secure!
 936  
 937  ##### Prevent code reuse attacks
 938  
 939  `PAX_RAP`\
 940  
 941      By saying Y here the kernel will check indirect control transfers
 942      in order to detect and prevent attacks that try to hijack control
 943      flow by overwriting code pointers.
 944  
 945      If you have an amd64 processor that does not support SMEP then you
 946      must also enable a KERNEXEC code pointer instrumentation method
 947      (see PAX_KERNEXEC_PLUGIN).
 948  
 949      Note that binary modules cannot be instrumented by this approach.
 950  
 951      Note that the implementation requires a gcc with plugin support,
 952      i.e., gcc 4.5 or newer.  You may need to install the supporting
 953      headers explicitly in addition to the normal gcc package.
 954  
 955  ##### Forward edge defense (deterministic)
 956  
 957  `PAX_RAP_CALL`\
 958  
 959  ##### Forward edge defense instrumentation method
 960  
 961      Some processors are susceptible to certain speculative execution
 962      based attacks.  This option selects the instrumentation kind for
 963      the forward edge defense with different tradeoffs between security,
 964      performance and information about control flow violations.
 965  
 966      Note that each instrumentation method for the forward edge defense
 967      provides the same security level for normal (non-speculative)
 968      execution, they differ only under speculative execution on affected
 969      processors.
 970  
 971      Kernels built to run purely on AMD systems with an updated
 972      microcode and CONFIG_RETPOLINE enabled should enable the "callabort"
 973      method for improved performance and reporting ability.  Such systems
 974      are not able to perform speculative ROP attacks in the kernel.
 975  
 976  ###### callabort
 977  
 978  `PAX_RAP_CALL_ABORT`\
 979  
 980      This instrumentation method provides the best performance
 981      and is able to provide full details for control flow
 982      violations but it may be susceptible to speculative
 983      execution based attacks under certain circumstances.
 984  
 985  ###### callnospec
 986  
 987  `PAX_RAP_CALL_NOSPEC`\
 988  
 989      This instrumentation is safe from speculation based attacks
 990      but has a worse performance impact and provides only partial
 991      details for control flow violations (the unintended, possibly
 992      hijacked, control flow target may not be discoverable).
 993  
 994      Kernels built to run purely on AMD systems with an updated
 995      microcode and CONFIG_RETPOLINE enabled should not enable this
 996      option to benefit from improved performance and reporting
 997      ability.  Such systems are not able to speculatively perform
 998      ROP attacks in the kernel.
 999  
1000      Note that this feature requires gcc 4.8 or newer.
1001  
1002  ##### Backward edge defense (deterministic)
1003  
1004  `PAX_RAP_RET`\
1005  
1006  ##### Backward edge defense (probabilistic)
1007  
1008  `PAX_RAP_XOR`\
1009  
1010  ##### Automatically protect kernel code vulnerable to Spectre v1
1011  
1012  `PAX_RESPECTRE_PLUGIN`\
1013  
1014      By saying Y here the compiler will automatically find and protect
1015      kernel code that may be vulnerable to CVE-2017-5753 (Spectre v1).
1016      The defense ensures that speculative array accesses use either
1017      a properly bounded or non-speculated index.  There are two defense
1018      types: index masking and fencing.  The former is preferred due to
1019      its negligible performance impact but it is not always feasible to
1020      use it so fencing is used in such cases.
1021  
1022      While the performance impact of the instrumentation should be mostly
1023      negligible (fencing is rarely used and even then its impact is quite
1024      processor dependent), you should measure it on your particular
1025      workload before deployment.
1026  
1027      Note that the implementation requires a gcc with plugin support,
1028      i.e., gcc 4.5 or newer.  You may need to install the supporting
1029      headers explicitly in addition to the normal gcc package.
1030  
1031  ##### Protect more kernel code vulnerable to Spectre v1
1032  
1033  `PAX_RESPECTRE_PLUGIN_LOOPINDEX`\
1034  
1035      By saying Y here the compiler will protect more kernel code from
1036      Spectre v1 attacks where the potentially vulnerable instances depend
1037      on a loop index variable and speculative loop overexecution.  In such
1038      cases the processor can speculatively execute a loop more times than
1039      the intended loop count which can result in speculative uses of
1040      out-of-bound pointers and other invalid data.
1041  
1042      As the number of such cases is over 5 times of the 'normal' Spectre
1043      v1 instrumentation, the performance impact needs to be carefully
1044      measured before enabling this option.
1045  
1046  ##### Automatically protect kernel code vulnerable to Spectre v4
1047  
1048  `PAX_RESPECTRE_PLUGIN_SSB`\
1049  
1050      By saying Y here the compiler will automatically find and protect
1051      kernel code that may be vulnerable to CVE-2018-3639 (Spectre v4).
1052      The defense is fencing that ensures that speculative loads of an
1053      array index variable do not bypass earlier stores to the index.
1054  
1055      Note that this defense does not apply to user programs therefore
1056      if you want to protect them as well you must enable some form of
1057      the SSBD defense instead, see the kernel documentation about
1058      'spec_store_bypass_disable'.
1059  
1060      Note that in order to reduce performance impact, the static analysis
1061      is specifically tailored to finding problematic stores and loads
1062      inside the same function only.  Nevertheless, you should measure its
1063      performance impact before deployment and also compare it to that of
1064      the full SSBD defense which also protects the kernel.
1065  
1066  ##### Protect more kernel code vulnerable to Spectre v4
1067  
1068  `PAX_RESPECTRE_PLUGIN_SSB_ALL`\
1069  
1070      By saying Y here the compiler will protect more kernel code from
1071      Spectre v4 attacks where the potentially vulnerable instances can
1072      cross function boundaries.
1073  
1074      As the number of such cases is about 25 times of the 'normal' Spectre
1075      v4 instrumentation, the performance impact needs to be carefully
1076      measured before enabling this option.
1077  
1078  ##### Report code found to be potentially vulnerable to Spectre v1/v4
1079  
1080  `PAX_RESPECTRE_PLUGIN_VERBOSE`\
1081  
1082      Print out statements deemed vulnerable to Spectre v1/v4 along with
1083      the chosen defense type during compilation.
1084  
1085  ##### Convert k\*alloc allocations into their own slabs
1086  
1087  `PAX_AUTOSLAB_PLUGIN`\
1088  
1089      Convert generic memory allocations of candidate types into type
1090      specific slab allocations.  This can help reduce memory fragmentation
1091      and will stop the exploit technique that relies on type confusion
1092      between objects of different types that would otherwise be allocated
1093      from the same generic slab.
1094  
1095      Note that autoslabs with live objects created by a kernel module
1096      will not be destroyed when unloading the module, resulting in a small
1097      memory leak on such module unloads.  Live objects at module unload
1098      time will be logged; in most instances, this will point to real memory
1099      leak bugs in the kernel.
1100  
1101      Note that this feature requires gcc 4.6 or newer.
1102  
1103  ##### Convert small k\*alloc allocations to local variables
1104  
1105  `PAX_AUTOSLAB_PLUGIN_AUTOSTACK`\
1106  
1107      Some generic memory allocations are equivalent to and thus can be
1108      converted to a local variable when they meet certain criteria.
1109  
1110  ##### Report autoslab decisions
1111  
1112  `PAX_AUTOSLAB_PLUGIN_VERBOSE`\
1113  
1114      Print out when an autoslab conversion took place or why it did not.
1115  
1116  ##### Report some potential NULL pointer dereferences
1117  
1118  `PAX_REPORT_NULL_DEREF`\
1119  
1120      Report some NULL pointer dereferences that gcc was unable to eliminate
1121      during optimization.  Note that these may or may not be real bugs but
1122      are worth a look regardless as the code should at least be refactored.
1123  
1124  ### Memory Protections
1125  
1126  #### Deny reading/writing to /dev/kmem, /dev/mem, and /dev/port
1127  
1128  `GRKERNSEC_KMEM`\
1129  
1130      If you say Y here, /dev/kmem and /dev/mem won't be allowed to
1131      be written to or read from to modify or leak the contents of the running
1132      kernel.  /dev/port will also not be allowed to be opened, writing to
1133      /dev/cpu/*/msr will be prevented, and support for kexec will be removed.
1134      If you have module support disabled, enabling this will close up several
1135      ways that are currently used to insert malicious code into the running
1136      kernel.
1137  
1138      Even with this feature enabled, we still highly recommend that
1139      you use the RBAC system, as it is still possible for an attacker to
1140      modify the running kernel through other more obscure methods.
1141  
1142      Enabling this feature will prevent the "cpupower" and "powertop" tools
1143      from working and excludes debugfs from being compiled into the kernel.
1144  
1145      It is highly recommended that you say Y here if you meet all the
1146      conditions above.
1147  
1148  #### Restrict VM86 mode
1149  
1150  `GRKERNSEC_VM86`\
1151  
1152      If you say Y here, only processes with CAP_SYS_RAWIO will be able to
1153      make use of a special execution mode on 32bit x86 processors called
1154      Virtual 8086 (VM86) mode.  XFree86 may need vm86 mode for certain
1155      video cards and will still work with this option enabled.  The purpose
1156      of the option is to prevent exploitation of emulation errors in
1157      virtualization of vm86 mode like the one discovered in VMWare in 2009.
1158      Nearly all users should be able to enable this option.
1159  
1160  #### Disable privileged I/O
1161  
1162  `GRKERNSEC_IO`\
1163  Related sysctl variables:\
1164  :`kernel.grsecurity.disable_priv_io`
1165  
1166      If you say Y here, all ioperm and iopl calls will return an error.
1167      Ioperm and iopl can be used to modify the running kernel.
1168      Unfortunately, some programs need this access to operate properly,
1169      the most notable of which are XFree86 and hwclock.  hwclock can be
1170      remedied by having RTC support in the kernel, so real-time 
1171      clock support is enabled if this option is enabled, to ensure 
1172      that hwclock operates correctly.  If hwclock still does not work,
1173      either update udev or symlink /dev/rtc to /dev/rtc0.
1174  
1175      If you're using XFree86 or a version of Xorg from 2012 or earlier,
1176      you may not be able to boot into a graphical environment with this
1177      option enabled.  In this case, you should use the RBAC system instead.
1178  
1179  #### Harden BPF interpreter
1180  
1181  `GRKERNSEC_BPF_HARDEN`\
1182  
1183      Enabling this option will automatically configure the kernel's BPF
1184      JIT with the most secure settings.
1185  
1186      If you're using KERNEXEC, it's recommended that you enable this option
1187      to supplement the hardening of the kernel.
1188  
1189  #### Disable unprivileged PERF\_EVENTS usage by default
1190  
1191  `GRKERNSEC_PERF_HARDEN`\
1192  
1193      If you say Y here, the range of acceptable values for the
1194      /proc/sys/kernel/perf_event_paranoid sysctl will be expanded to allow and
1195      default to a new value: 3.  When the sysctl is set to this value, no
1196      unprivileged use of the PERF_EVENTS syscall interface will be permitted.
1197  
1198      Though PERF_EVENTS can be used legitimately for performance monitoring
1199      and low-level application profiling, it is forced on regardless of
1200      configuration, has been at fault for several vulnerabilities, and
1201      creates new opportunities for side channels and other information leaks.
1202  
1203      This feature puts PERF_EVENTS into a secure default state and permits
1204      the administrator to change out of it temporarily if unprivileged
1205      application profiling is needed.
1206  
1207  #### Insert random gaps between thread stacks
1208  
1209  `GRKERNSEC_RAND_THREADSTACK`\
1210  
1211      If you say Y here, a random-sized gap will be enforced between allocated
1212      thread stacks.  Glibc's NPTL and other threading libraries that
1213      pass MAP_STACK to the kernel for thread stack allocation are supported.
1214      The implementation currently provides 8 bits of entropy for the gap.
1215  
1216      Many distributions do not compile threaded remote services with the
1217      -fstack-check argument to GCC, causing the variable-sized stack-based
1218      allocator, alloca(), to not probe the stack on allocation.  This
1219      permits an unbounded alloca() to skip over any guard page and potentially
1220      modify another thread's stack reliably.  An enforced random gap
1221      reduces the reliability of such an attack and increases the chance
1222      that such a read/write to another thread's stack instead lands in
1223      an unmapped area, causing a crash and triggering grsecurity's
1224      anti-bruteforcing logic.
1225  
1226  #### Harden ASLR against information leaks and entropy reduction
1227  
1228  `GRKERNSEC_PROC_MEMMAP`\
1229  
1230      If you say Y here, the /proc/<pid>/maps and /proc/<pid>/stat files will
1231      give no information about the addresses of its mappings if
1232      PaX features that rely on random addresses are enabled on the task.
1233      In addition to sanitizing this information and disabling other
1234      dangerous sources of information, this option causes reads of sensitive
1235      /proc/<pid> entries where the file descriptor was opened in a different
1236      task than the one performing the read.  Such attempts are logged.
1237      This option also limits argv/env strings for suid/sgid binaries
1238      to 512KB to prevent a complete exhaustion of the stack entropy provided
1239      by ASLR.  Finally, it places an 8MB stack resource limit on suid/sgid
1240      binaries to prevent alternative mmap layouts from being abused.
1241  
1242      If you use PaX it is essential that you say Y here as it closes up
1243      several holes that make full ASLR useless locally.
1244  
1245  #### Prevent kernel stack overflows
1246  
1247  `GRKERNSEC_KSTACKOVERFLOW`\
1248  
1249      If you say Y here, the kernel's process stacks will be allocated
1250      with vmalloc instead of the kernel's default allocator.  This
1251      introduces guard pages that in combination with the alloca checking
1252      of the STACKLEAK feature and removal of thread_info from the kernel
1253      stack prevents all forms of kernel process stack overflow abuse.
1254      Note that this is different from kernel stack buffer overflows.
1255  
1256  #### Deter exploit bruteforcing
1257  
1258  `GRKERNSEC_BRUTE`\
1259  Related sysctl variables:\
1260  :`kernel.grsecurity.deter_bruteforce`
1261  
1262      If you say Y here, attempts to bruteforce exploits against forking
1263      daemons such as apache or sshd, as well as against suid/sgid binaries
1264      will be deterred.  When a child of a forking daemon is killed by PaX
1265      or crashes due to an illegal instruction or other suspicious signal,
1266      the parent process will be delayed 30 seconds upon every subsequent
1267      fork until the administrator is able to assess the situation and
1268      restart the daemon.
1269      In the suid/sgid case, the attempt is logged, the user has all their
1270      existing instances of the suid/sgid binary terminated and will
1271      be unable to execute any suid/sgid binaries for 15 minutes.
1272  
1273      It is recommended that you also enable signal logging in the auditing
1274      section so that logs are generated when a process triggers a suspicious
1275      signal.
1276      If the sysctl option is enabled, a sysctl option with name
1277      "deter_bruteforce" is created.
1278  
1279  #### Harden module auto-loading
1280  
1281  `GRKERNSEC_MODHARDEN`\
1282  
1283      If you say Y here, module auto-loading in response to use of some
1284      feature implemented by an unloaded module will be restricted to
1285      root users.  Enabling this option helps defend against attacks 
1286      by unprivileged users who abuse the auto-loading behavior to 
1287      cause a vulnerable module to load that is then exploited.
1288  
1289      If this option prevents a legitimate use of auto-loading for a 
1290      non-root user, the administrator can execute modprobe manually 
1291      with the exact name of the module mentioned in the alert log.
1292      Alternatively, the administrator can add the module to the list
1293      of modules loaded at boot by modifying init scripts.
1294  
1295      Modification of init scripts will most likely be needed on 
1296      Ubuntu servers with encrypted home directory support enabled,
1297      as the first non-root user logging in will cause the ecb(aes),
1298      ecb(aes)-all, cbc(aes), and cbc(aes)-all  modules to be loaded.
1299  
1300  #### Hide kernel symbols
1301  
1302  `GRKERNSEC_HIDESYM`\
1303  
1304      If you say Y here, getting information on loaded modules, and
1305      displaying all kernel symbols through a syscall will be restricted
1306      to users with CAP_SYS_MODULE.  For software compatibility reasons,
1307      /proc/kallsyms will be restricted to the root user.  The RBAC
1308      system can hide that entry even from root.
1309  
1310      This option also prevents leaking of kernel addresses through
1311      several /proc entries.
1312  
1313      Note that this option is only effective provided the following
1314      conditions are met:
1315      1) The kernel using grsecurity is not precompiled by some distribution
1316      2) You have also enabled GRKERNSEC_DMESG
1317      3) You are using the RBAC system and hiding other files such as your
1318         kernel image and System.map.  Alternatively, enabling this option
1319         causes the permissions on /boot, /lib/modules, and the kernel
1320         source directory to change at compile time to prevent 
1321         reading by non-root users.
1322      If the above conditions are met, this option will aid in providing a
1323      useful protection against local kernel exploitation of overflows
1324      and arbitrary read/write vulnerabilities.
1325  
1326      It is highly recommended that you enable GRKERNSEC_PERF_HARDEN
1327      in addition to this feature.
1328  
1329  #### Randomize layout of sensitive kernel structures
1330  
1331  `GRKERNSEC_RANDSTRUCT`\
1332  
1333      If you say Y here, the layouts of a number of sensitive kernel
1334      structures (task, fs, cred, etc) and all structures composed entirely
1335      of function pointers (aka "ops" structs) will be randomized at compile-time.
1336      This can introduce the requirement of an additional infoleak
1337      vulnerability for exploits targeting these structure types.
1338  
1339      Enabling this feature will introduce some performance impact, slightly
1340      increase memory usage, and prevent the use of forensic tools like
1341      Volatility against the system (unless the kernel source tree isn't
1342      cleaned after kernel installation).
1343  
1344      The seed used for compilation is located at scripts/gcc-plugins/randomize_layout_seed.h.
1345      It remains after a make clean to allow for external modules to be compiled
1346      with the existing seed and will be removed by a make mrproper or
1347      make distclean.
1348  
1349      Note that the implementation requires gcc 4.6.4. or newer.  You may need
1350      to install the supporting headers explicitly in addition to the normal
1351      gcc package.
1352  
1353  #### Use cacheline-aware structure randomization
1354  
1355  `GRKERNSEC_RANDSTRUCT_PERFORMANCE`\
1356  
1357      If you say Y here, the RANDSTRUCT randomization will make a best effort
1358      at restricting randomization to cacheline-sized groups of elements.
1359      This reduces the performance hit of RANDSTRUCT at the cost of weakened
1360      randomization.
1361  
1362  #### Active kernel exploit response
1363  
1364  `GRKERNSEC_KERN_LOCKOUT`\
1365  
1366      If you say Y here, when a PaX alert is triggered due to suspicious
1367      activity in the kernel (from KERNEXEC/UDEREF/USERCOPY)
1368      or an OOPS occurs due to bad memory accesses, instead of just
1369      terminating the offending process (and potentially allowing
1370      a subsequent exploit from the same user), we will take one of two
1371      actions:
1372       If the user was root, we will panic the system
1373       If the user was non-root, we will log the attempt, terminate
1374       all processes owned by the user, then prevent them from creating
1375       any new processes until the system is restarted
1376      This deters repeated kernel exploitation/bruteforcing attempts
1377      and is useful for later forensics.
1378  
1379  #### Old ARM userland compatibility
1380  
1381  `GRKERNSEC_OLD_ARM_USERLAND`\
1382  
1383      If you say Y here, stubs of executable code to perform such operations
1384      as "compare-exchange" will be placed at fixed locations in the ARM vector
1385      table.  This is unfortunately needed for old ARM userland meant to run
1386      across a wide range of processors.  Without this option enabled,
1387      the get_tls and data memory barrier stubs will be emulated by the kernel,
1388      which is enough for Linaro userlands or other userlands designed for v6
1389      and newer ARM CPUs.  It's recommended that you try without this option enabled
1390      first, and only enable it if your userland does not boot (it will likely fail
1391      at init time).
1392  
1393  ### Role Based Access Control Options
1394  
1395  #### Disable RBAC system
1396  
1397  `GRKERNSEC_NO_RBAC`\
1398  
1399      If you say Y here, the /dev/grsec device will be removed from the kernel,
1400      preventing the RBAC system from being enabled.  You should only say Y
1401      here if you have no intention of using the RBAC system, so as to prevent
1402      an attacker with root access from misusing the RBAC system to hide files
1403      and processes when loadable module support and /dev/[k]mem have been
1404      locked down.
1405  
1406  #### Hide kernel processes
1407  
1408  `GRKERNSEC_ACL_HIDEKERN`\
1409  
1410      If you say Y here, all kernel threads will be hidden to all
1411      processes but those whose subject has the "view hidden processes"
1412      flag.
1413  
1414  #### Maximum tries before password lockout
1415  
1416  `GRKERNSEC_ACL_MAXTRIES`\
1417  
1418      This option enforces the maximum number of times a user can attempt
1419      to authorize themselves with the grsecurity RBAC system before being
1420      denied the ability to attempt authorization again for a specified time.
1421      The lower the number, the harder it will be to brute-force a password.
1422  
1423  #### Time to wait after max password tries, in seconds
1424  
1425  `GRKERNSEC_ACL_TIMEOUT`\
1426  
1427      This option specifies the time the user must wait after attempting to
1428      authorize to the RBAC system with the maximum number of invalid
1429      passwords.  The higher the number, the harder it will be to brute-force
1430      a password.
1431  
1432  ### Filesystem Protections
1433  
1434  #### Proc restrictions
1435  
1436  `GRKERNSEC_PROC`\
1437  
1438      If you say Y here, the permissions of the /proc filesystem
1439      will be altered to enhance system security and privacy.  You MUST
1440      choose either a user only restriction or a user and group restriction.
1441      Depending upon the option you choose, you can either restrict users to
1442      see only the processes they themselves run, or choose a group that can
1443      view all processes and files normally restricted to root if you choose
1444      the "restrict to user only" option.  NOTE: If you're running identd or
1445      ntpd as a non-root user, you will have to run it as the group you
1446      specify here.
1447  
1448  #### Restrict /proc to user only
1449  
1450  `GRKERNSEC_PROC_USER`\
1451  
1452      If you say Y here, non-root users will only be able to view their own
1453      processes, and restricts them from viewing network-related information,
1454      and viewing kernel symbol and module information.
1455  
1456  #### Allow special group
1457  
1458  `GRKERNSEC_PROC_USERGROUP`\
1459  
1460      If you say Y here, you will be able to select a group that will be
1461      able to view all processes and network-related information.  If you've
1462      enabled GRKERNSEC_HIDESYM, kernel and symbol information may still
1463      remain hidden.  This option is useful if you want to run identd as
1464      a non-root user.  The group you select may also be chosen at boot time
1465      via "grsec_proc_gid=" on the kernel commandline.
1466  
1467  #### GID exempted from /proc restrictions
1468  
1469  `GRKERNSEC_PROC_GID`\
1470  
1471      Setting this GID determines which group will be exempted from
1472      grsecurity's /proc restrictions, allowing users of the specified
1473      group  to view network statistics and the existence of other users'
1474      processes on the system.  This GID may also be chosen at boot time
1475      via "grsec_proc_gid=" on the kernel commandline.
1476  
1477  #### Additional restrictions
1478  
1479  `GRKERNSEC_PROC_ADD`\
1480  
1481      If you say Y here, additional restrictions will be placed on
1482      /proc that keep normal users from viewing device information and 
1483      slabinfo information that could be useful for exploits.
1484  
1485  #### Linking restrictions
1486  
1487  `GRKERNSEC_LINK`\
1488  Related sysctl variables:\
1489  :`kernel.grsecurity.linking_restrictions`
1490  
1491      If you say Y here, /tmp race exploits will be prevented, since users
1492      will no longer be able to follow symlinks owned by other users in
1493      world-writable +t directories (e.g. /tmp), unless the owner of the
1494      symlink is the owner of the directory. users will also not be
1495      able to hardlink to files they do not own.  If the sysctl option is
1496      enabled, a sysctl option with name "linking_restrictions" is created.
1497  
1498  #### Kernel-enforced SymlinksIfOwnerMatch
1499  
1500  `GRKERNSEC_SYMLINKOWN`\
1501  Related sysctl variables:\
1502  :`kernel.grsecurity.enforce_symlinksifowner`
1503  
1504  :   `kernel.grsecurity.symlinkown_gid`
1505  
1506  <!-- -->
1507  
1508      Apache's SymlinksIfOwnerMatch option has an inherent race condition
1509      that prevents it from being used as a security feature.  As Apache
1510      verifies the symlink by performing a stat() against the target of
1511      the symlink before it is followed, an attacker can setup a symlink
1512      to point to a same-owned file, then replace the symlink with one
1513      that targets another user's file just after Apache "validates" the
1514      symlink -- a classic TOCTOU race.  If you say Y here, a complete,
1515      race-free replacement for Apache's "SymlinksIfOwnerMatch" option
1516      will be in place for the group you specify. If the sysctl option
1517      is enabled, a sysctl option with name "enforce_symlinksifowner" is
1518      created.
1519  
1520  #### GID for users with kernel-enforced SymlinksIfOwnerMatch
1521  
1522  `GRKERNSEC_SYMLINKOWN_GID`\
1523  
1524      Setting this GID determines what group kernel-enforced
1525      SymlinksIfOwnerMatch will be enabled for.  If the sysctl option
1526      is enabled, a sysctl option with name "symlinkown_gid" is created.
1527  
1528  #### FIFO restrictions
1529  
1530  `GRKERNSEC_FIFO`\
1531  Related sysctl variables:\
1532  :`kernel.grsecurity.fifo_restrictions`
1533  
1534      If you say Y here, users will not be able to write to FIFOs they don't
1535      own in world-writable +t directories (e.g. /tmp), unless the owner of
1536      the FIFO is the same owner of the directory it's held in.  If the sysctl
1537      option is enabled, a sysctl option with name "fifo_restrictions" is
1538      created.
1539  
1540  #### Sysfs/debugfs restriction
1541  
1542  `GRKERNSEC_SYSFS_RESTRICT`\
1543  Related sysctl variables:\
1544  :`kernel.grsecurity.enforce_sysfs_restrict`
1545  
1546      If you say Y here, sysfs (the pseudo-filesystem mounted at /sys) and
1547      any filesystem normally mounted under it (e.g. debugfs) will be
1548      mostly accessible only by root.  These filesystems generally provide access
1549      to hardware and debug information that isn't appropriate for unprivileged
1550      users of the system.  Sysfs and debugfs have also become a large source
1551      of new vulnerabilities, ranging from infoleaks to local compromise.
1552      There has been very little oversight with an eye toward security involved
1553      in adding new exporters of information to these filesystems, so their
1554      use is discouraged.
1555      For reasons of compatibility, a few directories have been whitelisted
1556      for access by non-root users:
1557      /sys/fs/selinux
1558      /sys/fs/fuse
1559      /sys/devices/system/cpu
1560  
1561      If the sysctl option is enabled, a sysctl option with name
1562      "enforce_sysfs_restrict" is created to control the sysfs side
1563      of this protection at runtime.
1564  
1565      At kernel boot time, the grsec_sysfs_restrict=0 option can be
1566      used on the kernel commandline to disable both the sysfs and
1567      debugfs aspects of this feature.
1568  
1569      Please note that for backward compatibility reasons, the enforce_sysfs_restrict
1570      option will default to on regardless of any other grsecurity settings.
1571  
1572  #### Allow special group to bypass sysfs restrictions
1573  
1574  `GRKERNSEC_SYSFS_RESTRICT_GROUP`\
1575  Related sysctl variables:\
1576  :`kernel.grsecurity.sysfs_restrict_bypass_gid`
1577  
1578      If you say Y here, you will be able to select a group that will be
1579      able to bypass the sysfs restrictions of GRKERNSEC_SYSFS_RESTRICT.
1580      While we aim to whitelist obviously safe entries for compatibility
1581      purposes, this may not always be possible, so this additional group
1582      can be used to fill that compatibility need if it arises.
1583  
1584  #### GID for users that bypass sysfs restrictions
1585  
1586  `GRKERNSEC_SYSFS_RESTRICT_GID`\
1587  
1588      Setting this GID determines what group bypassing of sysfs restrictions
1589      will be permitted for. If the sysctl option is enabled, a sysctl option
1590      with name "sysfs_restrict_bypass_gid" is created.
1591  
1592  #### Runtime read-only mount protection
1593  
1594  `GRKERNSEC_ROFS`\
1595  Related sysctl variables:\
1596  :`kernel.grsecurity.romount_protect`
1597  
1598      If you say Y here, a sysctl option with name "romount_protect" will
1599      be created.  By setting this option to 1 at runtime, filesystems
1600      will be protected in the following ways:
1601      * No new writable mounts will be allowed
1602      * Existing read-only mounts won't be able to be remounted read/write
1603      * Write operations will be denied on all block devices
1604      This option acts independently of grsec_lock: once it is set to 1,
1605      it cannot be turned off.  Therefore, please be mindful of the resulting
1606      behavior if this option is enabled in an init script on a read-only
1607      filesystem.
1608      Also be aware that as with other root-focused features, GRKERNSEC_KMEM
1609      and GRKERNSEC_IO should be enabled and module loading disabled via
1610      config or at runtime.
1611      This feature is mainly intended for secure embedded systems.
1612  
1613  #### Eliminate stat/notify-based device sidechannels
1614  
1615  `GRKERNSEC_DEVICE_SIDECHANNEL`\
1616  
1617      If you say Y here, timing analyses on block or character
1618      devices like /dev/ptmx using stat or inotify/dnotify/fanotify
1619      will be thwarted for unprivileged users.  If a process without
1620      CAP_MKNOD stats such a device, the last access and last modify times
1621      will match the device's create time.  No access or modify events
1622      will be triggered through inotify/dnotify/fanotify for such devices.
1623      This feature will prevent attacks that may at a minimum
1624      allow an attacker to determine the administrator's password length.
1625  
1626  #### Chroot jail restrictions
1627  
1628  `GRKERNSEC_CHROOT`\
1629  
1630      If you say Y here, you will be able to choose several options that will
1631      make breaking out of a chrooted jail much more difficult.  If you
1632      encounter no software incompatibilities with the following options, it
1633      is recommended that you enable each one.
1634  
1635      Note that the chroot restrictions are not intended to apply to "chroots"
1636      to directories that are simple bind mounts of the global root filesystem.
1637      For several other reasons, a user shouldn't expect any significant
1638      security by performing such a chroot.
1639  
1640  #### Deny mounts
1641  
1642  `GRKERNSEC_CHROOT_MOUNT`\
1643  Related sysctl variables:\
1644  :`kernel.grsecurity.chroot_deny_mount`
1645  
1646      If you say Y here, processes inside a chroot will not be able to
1647      mount or remount filesystems.  If the sysctl option is enabled, a
1648      sysctl option with name "chroot_deny_mount" is created.
1649  
1650  #### Deny double-chroots
1651  
1652  `GRKERNSEC_CHROOT_DOUBLE`\
1653  Related sysctl variables:\
1654  :`kernel.grsecurity.chroot_deny_chroot`
1655  
1656      If you say Y here, processes inside a chroot will not be able to chroot
1657      again outside the chroot.  This is a widely used method of breaking
1658      out of a chroot jail and should not be allowed.  If the sysctl 
1659      option is enabled, a sysctl option with name 
1660      "chroot_deny_chroot" is created.
1661  
1662  #### Deny pivot\_root in chroot
1663  
1664  `GRKERNSEC_CHROOT_PIVOT`\
1665  Related sysctl variables:\
1666  :`kernel.grsecurity.chroot_deny_pivot`
1667  
1668      If you say Y here, processes inside a chroot will not be able to use
1669      a function called pivot_root() that was introduced in Linux 2.3.41.  It
1670      works similar to chroot in that it changes the root filesystem.  This
1671      function could be misused in a chrooted process to attempt to break out
1672      of the chroot, and therefore should not be allowed.  If the sysctl
1673      option is enabled, a sysctl option with name "chroot_deny_pivot" is
1674      created.
1675  
1676  #### Enforce chdir(
1677  
1678  `GRKERNSEC_CHROOT_CHDIR`\
1679  Related sysctl variables:\
1680  :`kernel.grsecurity.chroot_enforce_chdir`
1681  
1682      If you say Y here, the current working directory of all newly-chrooted
1683      applications will be set to the the root directory of the chroot.
1684      The man page on chroot(2) states:
1685      Note that this call does not change  the  current  working
1686      directory,  so  that `.' can be outside the tree rooted at
1687      `/'.  In particular, the  super-user  can  escape  from  a
1688      `chroot jail' by doing `mkdir foo; chroot foo; cd ..'.
1689  
1690      It is recommended that you say Y here, since it's not known to break
1691      any software.  If the sysctl option is enabled, a sysctl option with
1692      name "chroot_enforce_chdir" is created.
1693  
1694  #### Deny (f)chmod +s
1695  
1696  `GRKERNSEC_CHROOT_CHMOD`\
1697  Related sysctl variables:\
1698  :`kernel.grsecurity.chroot_deny_chmod`
1699  
1700      If you say Y here, processes inside a chroot will not be able to chmod
1701      or fchmod files to make them have suid or sgid bits.  This protects
1702      against another published method of breaking a chroot.  If the sysctl
1703      option is enabled, a sysctl option with name "chroot_deny_chmod" is
1704      created.
1705  
1706  #### Deny fchdir and fhandle out of chroot
1707  
1708  `GRKERNSEC_CHROOT_FCHDIR`\
1709  Related sysctl variables:\
1710  :`kernel.grsecurity.chroot_deny_fchdir`
1711  
1712      If you say Y here, a well-known method of breaking chroots by fchdir'ing
1713      to a file descriptor of the chrooting process that points to a directory
1714      outside the filesystem will be stopped.  This option also prevents use of
1715      the recently-created syscall for opening files by a guessable "file handle"
1716      inside a chroot, as well as accessing relative paths outside of a
1717      directory passed in via file descriptor with openat and similar syscalls.
1718      If the sysctl option is enabled, a sysctl option with name "chroot_deny_fchdir"
1719      is created.
1720  
1721  #### Deny mknod
1722  
1723  `GRKERNSEC_CHROOT_MKNOD`\
1724  Related sysctl variables:\
1725  :`kernel.grsecurity.chroot_deny_mknod`
1726  
1727      If you say Y here, processes inside a chroot will not be allowed to
1728      mknod.  The problem with using mknod inside a chroot is that it
1729      would allow an attacker to create a device entry that is the same
1730      as one on the physical root of your system, which could range from
1731      anything from the console device to a device for your harddrive (which
1732      they could then use to wipe the drive or steal data).  It is recommended
1733      that you say Y here, unless you run into software incompatibilities.
1734      If the sysctl option is enabled, a sysctl option with name
1735      "chroot_deny_mknod" is created.
1736  
1737  #### Deny shmat() out of chroot
1738  
1739  `GRKERNSEC_CHROOT_SHMAT`\
1740  Related sysctl variables:\
1741  :`kernel.grsecurity.chroot_deny_shmat`
1742  
1743      If you say Y here, processes inside a chroot will not be able to attach
1744      to shared memory segments that were created outside of the chroot jail.
1745      It is recommended that you say Y here.  If the sysctl option is enabled,
1746      a sysctl option with name "chroot_deny_shmat" is created.
1747  
1748  #### Deny access to abstract AF\_UNIX sockets out of chroot
1749  
1750  `GRKERNSEC_CHROOT_UNIX`\
1751  Related sysctl variables:\
1752  :`kernel.grsecurity.chroot_deny_unix`
1753  
1754      If you say Y here, processes inside a chroot will not be able to
1755      connect to abstract (meaning not belonging to a filesystem) Unix
1756      domain sockets that were bound outside of a chroot.  It is recommended
1757      that you say Y here.  If the sysctl option is enabled, a sysctl option
1758      with name "chroot_deny_unix" is created.
1759  
1760  #### Protect outside processes
1761  
1762  `GRKERNSEC_CHROOT_FINDTASK`\
1763  Related sysctl variables:\
1764  :`kernel.grsecurity.chroot_findtask`
1765  
1766      If you say Y here, processes inside a chroot will not be able to
1767      kill, send signals with fcntl, ptrace, capget, getpgid, setpgid, 
1768      getsid, or view any process outside of the chroot.  If the sysctl
1769      option is enabled, a sysctl option with name "chroot_findtask" is
1770      created.
1771  
1772  #### Restrict priority changes
1773  
1774  `GRKERNSEC_CHROOT_NICE`\
1775  Related sysctl variables:\
1776  :`kernel.grsecurity.chroot_restrict_nice`
1777  
1778      If you say Y here, processes inside a chroot will not be able to raise
1779      the priority of processes in the chroot, or alter the priority of
1780      processes outside the chroot.  This provides more security than simply
1781      removing CAP_SYS_NICE from the process' capability set.  If the
1782      sysctl option is enabled, a sysctl option with name "chroot_restrict_nice"
1783      is created.
1784  
1785  #### Deny sysctl writes
1786  
1787  `GRKERNSEC_CHROOT_SYSCTL`\
1788  Related sysctl variables:\
1789  :`kernel.grsecurity.chroot_deny_sysctl`
1790  
1791      If you say Y here, an attacker in a chroot will not be able to
1792      write to sysctl entries, either by sysctl(2) or through a /proc
1793      interface.  It is strongly recommended that you say Y here. If the
1794      sysctl option is enabled, a sysctl option with name
1795      "chroot_deny_sysctl" is created.
1796  
1797  #### Deny bad renames
1798  
1799  `GRKERNSEC_CHROOT_RENAME`\
1800  Related sysctl variables:\
1801  :`kernel.grsecurity.chroot_deny_bad_rename`
1802  
1803      If you say Y here, an attacker in a chroot will not be able to
1804      abuse the ability to create double chroots to break out of the
1805      chroot by exploiting a race condition between a rename of a directory
1806      within a chroot against an open of a symlink with relative path
1807      components.  This feature will likewise prevent an accomplice outside
1808      a chroot from enabling a user inside the chroot to break out and make
1809      use of their credentials on the global filesystem.  Enabling this
1810      feature is essential to prevent root users from breaking out of a
1811      chroot. If the sysctl option is enabled, a sysctl option with name
1812      "chroot_deny_bad_rename" is created.
1813  
1814  #### Capability restrictions
1815  
1816  `GRKERNSEC_CHROOT_CAPS`\
1817  Related sysctl variables:\
1818  :`kernel.grsecurity.chroot_caps`
1819  
1820      If you say Y here, the capabilities on all processes within a
1821      chroot jail will be lowered to stop module insertion, raw i/o,
1822      system and net admin tasks, rebooting the system, modifying immutable
1823      files, modifying IPC owned by another, and changing the system time.
1824      This is left an option because it can break some apps.  Disable this
1825      if your chrooted apps are having problems performing those kinds of
1826      tasks.  If the sysctl option is enabled, a sysctl option with
1827      name "chroot_caps" is created.
1828  
1829  #### Exempt initrd tasks from restrictions
1830  
1831  `GRKERNSEC_CHROOT_INITRD`\
1832  
1833      If you say Y here, tasks started prior to init will be exempted from
1834      grsecurity's chroot restrictions.  This option is mainly meant to
1835      resolve Plymouth's performing privileged operations unnecessarily
1836      in a chroot.
1837  
1838  ### Kernel Auditing
1839  
1840  #### Single group for auditing
1841  
1842  `GRKERNSEC_AUDIT_GROUP`\
1843  Related sysctl variables:\
1844  :`kernel.grsecurity.audit_gid`
1845  
1846  :   `kernel.grsecurity.audit_group`
1847  
1848  <!-- -->
1849  
1850      If you say Y here, the exec and chdir logging features will only operate
1851      on a group you specify.  This option is recommended if you only want to
1852      watch certain users instead of having a large amount of logs from the
1853      entire system.  If the sysctl option is enabled, a sysctl option with
1854      name "audit_group" is created.
1855  
1856  #### GID for auditing
1857  
1858  `GRKERNSEC_AUDIT_GID`\
1859  
1860  #### Exec logging
1861  
1862  `GRKERNSEC_EXECLOG`\
1863  Related sysctl variables:\
1864  :`kernel.grsecurity.exec_logging`
1865  
1866      If you say Y here, all execve() calls will be logged (since the
1867      other exec*() calls are frontends to execve(), all execution
1868      will be logged).  Useful for shell-servers that like to keep track
1869      of their users.  If the sysctl option is enabled, a sysctl option with
1870      name "exec_logging" is created.
1871      WARNING: This option when enabled will produce a LOT of logs, especially
1872      on an active system.
1873  
1874  #### Resource logging
1875  
1876  `GRKERNSEC_RESLOG`\
1877  Related sysctl variables:\
1878  :`kernel.grsecurity.resource_logging`
1879  
1880      If you say Y here, all attempts to overstep resource limits will
1881      be logged with the resource name, the requested size, and the current
1882      limit.  It is highly recommended that you say Y here.  If the sysctl
1883      option is enabled, a sysctl option with name "resource_logging" is
1884      created.  If the RBAC system is enabled, the sysctl value is ignored.
1885  
1886  #### Log execs within chroot
1887  
1888  `GRKERNSEC_CHROOT_EXECLOG`\
1889  Related sysctl variables:\
1890  :`kernel.grsecurity.chroot_execlog`
1891  
1892      If you say Y here, all executions inside a chroot jail will be logged
1893      to syslog.  This can cause a large amount of logs if certain
1894      applications (eg. djb's daemontools) are installed on the system, and
1895      is therefore left as an option.  If the sysctl option is enabled, a
1896      sysctl option with name "chroot_execlog" is created.
1897  
1898  #### Ptrace logging
1899  
1900  `GRKERNSEC_AUDIT_PTRACE`\
1901  Related sysctl variables:\
1902  :`kernel.grsecurity.audit_ptrace`
1903  
1904      If you say Y here, all attempts to attach to a process via ptrace
1905      will be logged.  If the sysctl option is enabled, a sysctl option
1906      with name "audit_ptrace" is created.
1907  
1908  #### Chdir logging
1909  
1910  `GRKERNSEC_AUDIT_CHDIR`\
1911  Related sysctl variables:\
1912  :`kernel.grsecurity.audit_chdir`
1913  
1914      If you say Y here, all chdir() calls will be logged.  If the sysctl
1915      option is enabled, a sysctl option with name "audit_chdir" is created.
1916  
1917  #### (Un)Mount logging
1918  
1919  `GRKERNSEC_AUDIT_MOUNT`\
1920  Related sysctl variables:\
1921  :`kernel.grsecurity.audit_mount`
1922  
1923      If you say Y here, all mounts and unmounts will be logged.  If the
1924      sysctl option is enabled, a sysctl option with name "audit_mount" is
1925      created.
1926  
1927  #### Only log (un)mounts for the initial mount namespace
1928  
1929  `GRKERNSEC_AUDIT_MOUNT_INITNS_ONLY`\
1930  
1931      If you say Y here, GRKERNSEC_AUDIT_MOUNT's behavior will be modified such
1932      that only mounts/unmounts in the initial mount namespace will be logged.
1933      This will eliminate noise from systemd and other facilities that create
1934      mounts (generally for security purposes) within private mount namespaces
1935      for specific services that have opted in.
1936  
1937  #### Signal logging
1938  
1939  `GRKERNSEC_SIGNAL`\
1940  Related sysctl variables:\
1941  :`kernel.grsecurity.signal_logging`
1942  
1943      If you say Y here, certain important signals will be logged, such as
1944      SIGSEGV, which will as a result inform you of when a error in a program
1945      occurred, which in some cases could mean a possible exploit attempt.
1946      If the sysctl option is enabled, a sysctl option with name
1947      "signal_logging" is created.
1948  
1949  #### Fork failure logging
1950  
1951  `GRKERNSEC_FORKFAIL`\
1952  Related sysctl variables:\
1953  :`kernel.grsecurity.forkfail_logging`
1954  
1955      If you say Y here, all failed fork() attempts will be logged.
1956      This could suggest a fork bomb, or someone attempting to overstep
1957      their process limit.  If the sysctl option is enabled, a sysctl option
1958      with name "forkfail_logging" is created.
1959  
1960  #### Time change logging
1961  
1962  `GRKERNSEC_TIME`\
1963  Related sysctl variables:\
1964  :`kernel.grsecurity.timechange_logging`
1965  
1966      If you say Y here, any changes of the system clock will be logged.
1967      If the sysctl option is enabled, a sysctl option with name
1968      "timechange_logging" is created.
1969  
1970  #### /proc/<pid>/ipaddr support
1971  
1972  `GRKERNSEC_PROC_IPADDR`\
1973  
1974      If you say Y here, a new entry will be added to each /proc/<pid>
1975      directory that contains the IP address of the person using the task.
1976      The IP is carried across local TCP and AF_UNIX stream sockets.
1977      This information can be useful for IDS/IPSes to perform remote response
1978      to a local attack.  The entry is readable by only the owner of the
1979      process (and root if he has CAP_DAC_OVERRIDE, which can be removed via
1980      the RBAC system), and thus does not create privacy concerns.
1981  
1982  #### Denied RWX mmap/mprotect logging
1983  
1984  `GRKERNSEC_RWXMAP_LOG`\
1985  Related sysctl variables:\
1986  :`kernel.grsecurity.rwxmap_logging`
1987  
1988      If you say Y here, calls to mmap() and mprotect() with explicit
1989      usage of PROT_WRITE and PROT_EXEC together will be logged when
1990      denied by the PAX_MPROTECT feature.  This feature will also
1991      log other problematic scenarios that can occur when PAX_MPROTECT
1992      is enabled on a binary, like textrels and PT_GNU_STACK.  If the 
1993      sysctl option is enabled, a sysctl option with name "rwxmap_logging"
1994      is created.
1995  
1996  ### Executable Protections
1997  
1998  #### Dmesg(8) restriction
1999  
2000  `GRKERNSEC_DMESG`\
2001  Related sysctl variables:\
2002  :`kernel.grsecurity.dmesg`
2003  
2004      If you say Y here, non-root users will not be able to use dmesg(8)
2005      to view the contents of the kernel's circular log buffer.
2006      The kernel's log buffer often contains kernel addresses and other
2007      identifying information useful to an attacker in fingerprinting a
2008      system for a targeted exploit.
2009      If the sysctl option is enabled, a sysctl option with name "dmesg" is
2010      created.
2011  
2012  #### Deter ptrace-based process snooping
2013  
2014  `GRKERNSEC_HARDEN_PTRACE`\
2015  Related sysctl variables:\
2016  :`kernel.grsecurity.harden_ptrace`
2017  
2018      If you say Y here, TTY sniffers and other malicious monitoring
2019      programs implemented through ptrace will be defeated.  If you
2020      have been using the RBAC system, this option has already been
2021      enabled for several years for all users, with the ability to make
2022      fine-grained exceptions.
2023  
2024      This option only affects the ability of non-root users to ptrace
2025      processes that are not a descendent of the ptracing process.
2026      This means that strace ./binary and gdb ./binary will still work,
2027      but attaching to arbitrary processes will not.  If the sysctl
2028      option is enabled, a sysctl option with name "harden_ptrace" is
2029      created.
2030  
2031  #### Require read access to ptrace sensitive binaries
2032  
2033  `GRKERNSEC_PTRACE_READEXEC`\
2034  Related sysctl variables:\
2035  :`kernel.grsecurity.ptrace_readexec`
2036  
2037      If you say Y here, unprivileged users will not be able to ptrace unreadable
2038      binaries.  This option is useful in environments that
2039      remove the read bits (e.g. file mode 4711) from suid binaries to
2040      prevent infoleaking of their contents.  This option adds
2041      consistency to the use of that file mode, as the binary could normally
2042      be read out when run without privileges while ptracing.
2043  
2044      If the sysctl option is enabled, a sysctl option with name "ptrace_readexec"
2045      is created.
2046  
2047  #### Enforce consistent multithreaded privileges
2048  
2049  `GRKERNSEC_SETXID`\
2050  Related sysctl variables:\
2051  :`kernel.grsecurity.consistent_setxid`
2052  
2053      If you say Y here, a change from a root uid to a non-root uid
2054      in a multithreaded application will cause the resulting uids,
2055      gids, supplementary groups, and capabilities in that thread
2056      to be propagated to the other threads of the process.  In most
2057      cases this is unnecessary, as glibc will emulate this behavior
2058      on behalf of the application.  Other libcs do not act in the
2059      same way, allowing the other threads of the process to continue
2060      running with root privileges.  If the sysctl option is enabled,
2061      a sysctl option with name "consistent_setxid" is created.
2062  
2063  #### Disallow access to overly-permissive IPC objects
2064  
2065  `GRKERNSEC_HARDEN_IPC`\
2066  Related sysctl variables:\
2067  :`kernel.grsecurity.harden_ipc`
2068  
2069      If you say Y here, access to overly-permissive IPC objects (shared
2070      memory, message queues, and semaphores) will be denied for processes
2071      given the following criteria beyond normal permission checks:
2072      1) If the IPC object is world-accessible and the euid doesn't match
2073         that of the creator or current uid for the IPC object
2074      2) If the IPC object is group-accessible and the egid doesn't
2075         match that of the creator or current gid for the IPC object
2076      It's a common error to grant too much permission to these objects,
2077      with impact ranging from denial of service and information leaking to
2078      privilege escalation.  This feature was developed in response to
2079      research by Tim Brown:
2080      http://labs.portcullis.co.uk/whitepapers/memory-squatting-attacks-on-system-v-shared-memory/
2081      who found hundreds of such insecure usages.  Processes with
2082      CAP_IPC_OWNER are still permitted to access these IPC objects.
2083      If the sysctl option is enabled, a sysctl option with name
2084      "harden_ipc" is created.
2085  
2086  #### Disallow unprivileged use of command injection
2087  
2088  `GRKERNSEC_HARDEN_TTY`\
2089  Related sysctl variables:\
2090  :`kernel.grsecurity.harden_tty`
2091  
2092      If you say Y here, the ability to use the TIOCSTI ioctl for
2093      terminal command injection will be denied for unprivileged users.
2094      There are very few legitimate uses for this functionality and it
2095      has made vulnerabilities in several 'su'-like programs possible in
2096      the past.  Even without these vulnerabilities, it provides an
2097      attacker with an easy mechanism to move laterally among other
2098      processes within the same user's compromised session.
2099      By default, Linux allows unprivileged use of command injection as
2100      long as the injection is being performed into the same tty session.
2101      This feature makes that case the same as attempting to inject into
2102      another session, making any TIOCSTI use require CAP_SYS_ADMIN.
2103      If the sysctl option is enabled, a sysctl option with name
2104      "harden_tty" is created.
2105  
2106  #### Disable ability of suid root apps to execute unsafe files
2107  
2108  `GRKERNSEC_SUID_NO_UNPRIV_EXEC`\
2109  
2110      If you say Y here, suid root applications will not be able to mmap
2111      executable or execute files world-writable or not owned by root.
2112      This addresses both an exploitation technique (e.g. the struct
2113      service_user overwrite in Qualys' CVE-2021-3156 Sudo exploit) as
2114      well as a vulnerability class that has appeared in suid root
2115      executables in the past (e.g. CVE-2017-4915).  If the sysctl
2116      option is enabled, a sysctl option with name "suid_no_unpriv_exec"
2117      is created.
2118  
2119  #### Trusted Path Execution (TPE)
2120  
2121  `GRKERNSEC_TPE`\
2122  Related sysctl variables:\
2123  :`kernel.grsecurity.tpe`
2124  
2125  :   `kernel.grsecurity.tpe_gid`
2126  
2127  <!-- -->
2128  
2129      If you say Y here, you will be able to choose a gid to add to the
2130      supplementary groups of users you want to mark as "untrusted."
2131      These users will not be able to execute any files that are not in
2132      root-owned directories writable only by root.  If the sysctl option
2133      is enabled, a sysctl option with name "tpe" is created.
2134  
2135  #### Partially restrict all non-root users
2136  
2137  `GRKERNSEC_TPE_ALL`\
2138  Related sysctl variables:\
2139  :`kernel.grsecurity.tpe_restrict_all`
2140  
2141      If you say Y here, all non-root users will be covered under
2142      a weaker TPE restriction.  This is separate from, and in addition to,
2143      the main TPE options that you have selected elsewhere.  Thus, if a
2144      "trusted" GID is chosen, this restriction applies to even that GID.
2145      Under this restriction, all non-root users will only be allowed to
2146      execute files in directories they own that are not group or
2147      world-writable, or in directories owned by root and writable only by
2148      root.  If the sysctl option is enabled, a sysctl option with name
2149      "tpe_restrict_all" is created.
2150  
2151  #### Invert GID option
2152  
2153  `GRKERNSEC_TPE_INVERT`\
2154  Related sysctl variables:\
2155  :`kernel.grsecurity.tpe_invert`
2156  
2157      If you say Y here, the group you specify in the TPE configuration will
2158      decide what group TPE restrictions will be *disabled* for.  This
2159      option is useful if you want TPE restrictions to be applied to most
2160      users on the system.  If the sysctl option is enabled, a sysctl option
2161      with name "tpe_invert" is created.  Unlike other sysctl options, this
2162      entry will default to on for backward-compatibility.
2163  
2164  #### GID for TPE-untrusted users
2165  
2166  `GRKERNSEC_TPE_UNTRUSTED_GID`\
2167  
2168      Setting this GID determines what group TPE restrictions will be
2169      *enabled* for.  If the sysctl option is enabled, a sysctl option
2170      with name "tpe_gid" is created.
2171  
2172  #### GID for TPE-trusted users
2173  
2174  `GRKERNSEC_TPE_TRUSTED_GID`\
2175  
2176      Setting this GID determines what group TPE restrictions will be
2177      *disabled* for.  If the sysctl option is enabled, a sysctl option
2178      with name "tpe_gid" is created.
2179  
2180  ### Network Protections
2181  
2182  #### TCP/UDP blackhole and LAST\_ACK DoS prevention
2183  
2184  `GRKERNSEC_BLACKHOLE`\
2185  Related sysctl variables:\
2186  :`kernel.grsecurity.ip_blackhole`
2187  
2188  :   `kernel.grsecurity.lastack_retries`
2189  
2190  <!-- -->
2191  
2192      If you say Y here, neither TCP resets nor ICMP
2193      destination-unreachable packets will be sent in response to packets
2194      sent to ports for which no associated listening process exists.
2195      It will also prevent the sending of ICMP protocol unreachable packets
2196      in response to packets with unknown protocols.
2197      This feature supports both IPV4 and IPV6 and exempts the 
2198      loopback interface from blackholing.  Enabling this feature 
2199      makes a host more resilient to DoS attacks and reduces network
2200      visibility against scanners.
2201  
2202      The blackhole feature as-implemented is equivalent to the FreeBSD
2203      blackhole feature, as it prevents RST responses to all packets, not
2204      just SYNs.  Under most application behavior this causes no
2205      problems, but applications (like haproxy) may not close certain
2206      connections in a way that cleanly terminates them on the remote
2207      end, leaving the remote host in LAST_ACK state.  Because of this
2208      side-effect and to prevent intentional LAST_ACK DoSes, this
2209      feature also adds automatic mitigation against such attacks.
2210      The mitigation drastically reduces the amount of time a socket
2211      can spend in LAST_ACK state.  If you're using haproxy and not
2212      all servers it connects to have this option enabled, consider
2213      disabling this feature on the haproxy host.
2214  
2215      If the sysctl option is enabled, two sysctl options with names
2216      "ip_blackhole" and "lastack_retries" will be created.
2217      While "ip_blackhole" takes the standard zero/non-zero on/off
2218      toggle, "lastack_retries" uses the same kinds of values as
2219      "tcp_retries1" and "tcp_retries2".  The default value of 4
2220      prevents a socket from lasting more than 45 seconds in LAST_ACK
2221      state.
2222  
2223  #### Disable TCP Simultaneous Connect
2224  
2225  `GRKERNSEC_NO_SIMULT_CONNECT`\
2226  
2227      If you say Y here, a feature by Willy Tarreau will be enabled that
2228      removes a weakness in Linux's strict implementation of TCP that
2229      allows two clients to connect to each other without either entering
2230      a listening state.  The weakness allows an attacker to easily prevent
2231      a client from connecting to a known server provided the source port
2232      for the connection is guessed correctly.
2233  
2234      As the weakness could be used to prevent an antivirus or IPS from
2235      fetching updates, or prevent an SSL gateway from fetching a CRL,
2236      it should be eliminated by enabling this option.  Though Linux is
2237      one of few operating systems supporting simultaneous connect, it
2238      has no legitimate use in practice and is rarely supported by firewalls.
2239  
2240  #### Socket restrictions
2241  
2242  `GRKERNSEC_SOCKET`\
2243  
2244      If you say Y here, you will be able to choose from several options.
2245      If you assign a GID on your system and add it to the supplementary
2246      groups of users you want to restrict socket access to, this patch
2247      will perform up to three things, based on the option(s) you choose.
2248  
2249  #### Deny any sockets to group
2250  
2251  `GRKERNSEC_SOCKET_ALL`\
2252  Related sysctl variables:\
2253  :`kernel.grsecurity.socket_all`
2254  
2255  :   `kernel.grsecurity.socket_all_gid`
2256  
2257  <!-- -->
2258  
2259      If you say Y here, you will be able to choose a GID of whose users will
2260      be unable to connect to other hosts from your machine or run server
2261      applications from your machine.  If the sysctl option is enabled, a
2262      sysctl option with name "socket_all" is created.
2263  
2264  #### GID to deny all sockets for
2265  
2266  `GRKERNSEC_SOCKET_ALL_GID`\
2267  
2268      Here you can choose the GID to disable socket access for. Remember to
2269      add the users you want socket access disabled for to the GID
2270      specified here.  If the sysctl option is enabled, a sysctl option
2271      with name "socket_all_gid" is created.
2272  
2273  #### Deny client sockets to group
2274  
2275  `GRKERNSEC_SOCKET_CLIENT`\
2276  Related sysctl variables:\
2277  :`kernel.grsecurity.socket_client`
2278  
2279  :   `kernel.grsecurity.socket_client_gid`
2280  
2281  <!-- -->
2282  
2283      If you say Y here, you will be able to choose a GID of whose users will
2284      be unable to connect to other hosts from your machine, but will be
2285      able to run servers.  If this option is enabled, all users in the group
2286      you specify will have to use passive mode when initiating ftp transfers
2287      from the shell on your machine.  If the sysctl option is enabled, a
2288      sysctl option with name "socket_client" is created.
2289  
2290  #### GID to deny client sockets for
2291  
2292  `GRKERNSEC_SOCKET_CLIENT_GID`\
2293  
2294      Here you can choose the GID to disable client socket access for.
2295      Remember to add the users you want client socket access disabled for to
2296      the GID specified here.  If the sysctl option is enabled, a sysctl
2297      option with name "socket_client_gid" is created.
2298  
2299  #### Deny server sockets to group
2300  
2301  `GRKERNSEC_SOCKET_SERVER`\
2302  Related sysctl variables:\
2303  :`kernel.grsecurity.socket_server`
2304  
2305  :   `kernel.grsecurity.socket_server_gid`
2306  
2307  <!-- -->
2308  
2309      If you say Y here, you will be able to choose a GID of whose users will
2310      be unable to run server applications from your machine.  If the sysctl
2311      option is enabled, a sysctl option with name "socket_server" is created.
2312  
2313  #### GID to deny server sockets for
2314  
2315  `GRKERNSEC_SOCKET_SERVER_GID`\
2316  
2317      Here you can choose the GID to disable server socket access for.
2318      Remember to add the users you want server socket access disabled for to
2319      the GID specified here.  If the sysctl option is enabled, a sysctl
2320      option with name "socket_server_gid" is created.
2321  
2322  ### Physical Protections
2323  
2324  #### Deny new USB connections after toggle
2325  
2326  `GRKERNSEC_DENYUSB`\
2327  
2328      If you say Y here, a new sysctl option with name "deny_new_usb"
2329      will be created.  Setting its value to 1 will prevent any new
2330      USB devices from being recognized by the OS.  Any attempted USB
2331      device insertion will be logged.  This option is intended to be
2332      used against custom USB devices designed to exploit vulnerabilities
2333      in various USB device drivers.
2334  
2335      For greatest effectiveness, this sysctl should be set after any
2336      relevant init scripts.  This option is safe to enable in distros
2337      as each user can choose whether or not to toggle the sysctl.
2338  
2339  #### Reject all USB devices not connected at boot
2340  
2341  `GRKERNSEC_DENYUSB_FORCE`\
2342  
2343      If you say Y here, a variant of GRKERNSEC_DENYUSB will be enabled
2344      that doesn't involve a sysctl entry.  This option should only be
2345      enabled if you're sure you want to deny all new USB connections
2346      at runtime and don't want to modify init scripts.  This should not
2347      be enabled by distros.  It forces the core USB code to be built
2348      into the kernel image so that all devices connected at boot time
2349      can be recognized and new USB device connections can be prevented
2350      prior to init running.
2351  
2352  ### Sysctl Support
2353  
2354  #### Sysctl support
2355  
2356  `GRKERNSEC_SYSCTL`\
2357  
2358      If you say Y here, you will be able to change the options that
2359      grsecurity runs with at bootup, without having to recompile your
2360      kernel.  You can echo values to files in /proc/sys/kernel/grsecurity
2361      to enable (1) or disable (0) various features.  All the sysctl entries
2362      are mutable until the "grsec_lock" entry is set to a non-zero value.
2363      All features enabled in the kernel configuration are disabled at boot
2364      if you do not say Y to the "Turn on features by default" option.
2365      All options should be set at startup, and the grsec_lock entry should
2366      be set to a non-zero value after all the options are set.
2367      *THIS IS EXTREMELY IMPORTANT*
2368  
2369  #### Extra sysctl support for distro makers (READ HELP)
2370  
2371  `GRKERNSEC_SYSCTL_DISTRO`\
2372  
2373      If you say Y here, additional sysctl options will be created
2374      for features that affect processes running as root.  Therefore,
2375      it is critical when using this option that the grsec_lock entry be
2376      enabled after boot.  Only distros with prebuilt kernel packages
2377      with this option enabled that can ensure grsec_lock is enabled
2378      after boot should use this option.
2379      *Failure to set grsec_lock after boot makes all grsec features
2380      this option covers useless*
2381  
2382      Currently this option creates the following sysctl entries:
2383      "Disable Privileged I/O": "disable_priv_io"
2384  
2385  #### Turn on features by default
2386  
2387  `GRKERNSEC_SYSCTL_ON`\
2388  
2389      If you say Y here, instead of having all features enabled in the
2390      kernel configuration disabled at boot time, the features will be
2391      enabled at boot time.  It is recommended you say Y here unless
2392      there is some reason you would want all sysctl-tunable features to
2393      be disabled by default.  As mentioned elsewhere, it is important
2394      to enable the grsec_lock entry once you have finished modifying
2395      the sysctl entries.
2396  
2397  ### Logging Options
2398  
2399  #### Seconds in between log messages (minimum)
2400  
2401  `GRKERNSEC_FLOODTIME`\
2402  
2403      This option allows you to enforce the number of seconds between
2404      grsecurity log messages.  The default should be suitable for most
2405      people, however, if you choose to change it, choose a value small enough
2406      to allow informative logs to be produced, but large enough to
2407      prevent flooding.
2408  
2409      Setting both this value and GRKERNSEC_FLOODBURST to 0 will disable
2410      any rate limiting on grsecurity log messages.
2411  
2412  #### Number of messages in a burst (maximum)
2413  
2414  `GRKERNSEC_FLOODBURST`\
2415  
2416      This option allows you to choose the maximum number of messages allowed
2417      within the flood time interval you chose in a separate option.  The
2418      default should be suitable for most people, however if you find that
2419      many of your logs are being interpreted as flooding, you may want to
2420      raise this value.
2421  
2422      Setting both this value and GRKERNSEC_FLOODTIME to 0 will disable
2423      any rate limiting on grsecurity log messages.