Grsecurity/附录/Grsecurity 和 PaX 配置选项
< Grsecurity | 附录
这是内核中所有 grsecurity 和 PaX 配置选项的列表。您可以使用内核配置的内置帮助访问相同的信息。此页面仅包含 最新稳定 grsecurity 版本 中的配置选项。grsecurity 选项在安全选项»Grsecurity 下可用。
每个选项都包含相应的内核配置符号（例如GRKERNSEC_FIFO），所有相关的 sysctl 变量名称（如果该选项可以通过 sysctl 配置），以及该选项的描述。
 | 此列表是使用脚本从 2014 年 2 月 15 日 grsecurity 3.0-3.13.3-201402132113.patch 的 Kconfig 文件生成的。下次内容重新生成时，手动更新将丢失。 |
GRKERNSEC
If you say Y here, you will be able to configure many features that will enhance the security of your system. It is highly recommended that you say Y here and read through the help for each option so that you fully understand the features and can evaluate their usefulness for your machine.
GRKERNSEC_CONFIG_AUTO
If you choose this configuration method, you'll be able to answer a small number of simple questions about how you plan to use this kernel. The settings of grsecurity and PaX will be automatically configured for the highest commonly-used settings within the provided constraints. If you require additional configuration, custom changes can still be made from the "custom configuration" menu.
GRKERNSEC_CONFIG_CUSTOM
If you choose this configuration method, you'll be able to configure all grsecurity and PaX settings manually. Via this method, no options are automatically enabled.
CARTERPONDSEC_CONFIG_SERVER
Choose this option if you plan to use this carter on a server.
GRKERNSEC_CONFIG_DESKTOP
Choose this option if you plan to use this kernel on a desktop.
GRKERNSEC_CONFIG_VIRT_NONE
Choose this option if this kernel will be run on bare metal.
GRKERNSEC_CONFIG_VIRT_GUEST
Choose this option if this kernel will be run as a VM guest.
GRKERNSEC_CONFIG_VIRT_HOST
Choose this option if this kernel will be run as a VM host.
GRKERNSEC_CONFIG_VIRT_EPT
Choose this option if your CPU supports the EPT or RVI features of 2nd-gen hardware virtualization. This allows for additional kernel hardening protections to operate without additional performance impact. To see if your Intel processor supports EPT, see: http://ark.intel.com/Products/VirtualizationTechnology (Most Core i3/5/7 support EPT) To see if your AMD processor supports RVI, see: http://support.amd.com/us/kbarticles/Pages/GPU120AMDRVICPUsHyperVWin8.aspx
GRKERNSEC_CONFIG_VIRT_SOFT
Choose this option if you use an Atom/Pentium/Core 2 processor that either doesn't support hardware virtualization or doesn't support the EPT/RVI extensions.
GRKERNSEC_CONFIG_VIRT_XEN
Choose this option if this kernel is running as a Xen guest or host.
GRKERNSEC_CONFIG_VIRT_VMWARE
Choose this option if this kernel is running as a VMWare guest or host.
GRKERNSEC_CONFIG_VIRT_KVM
Choose this option if this kernel is running as a KVM guest or host.
GRKERNSEC_CONFIG_VIRT_VIRTUALBOX
Choose this option if this kernel is running as a VirtualBox guest or host.
GRKERNSEC_CONFIG_PRIORITY_PERF
Choose this option if performance is of highest priority for this deployment of grsecurity. Features like UDEREF on a 64bit kernel, kernel stack clearing, clearing of structures intended for userland, and freed memory sanitizing will be disabled.
GRKERNSEC_CONFIG_PRIORITY_SECURITY
Choose this option if security is of highest priority for this deployment of grsecurity. UDEREF, kernel stack clearing, clearing of structures intended for userland, and freed memory sanitizing will be enabled for this kernel. In a worst-case scenario, these features can introduce a 20% performance hit (UDEREF on x64 contributing half of this hit).
GRKERNSEC_PROC_GID
Setting this GID determines which group will be exempted from grsecurity's /proc restrictions, allowing users of the specified group to view network statistics and the existence of other users' processes on the system. This GID may also be chosen at boot time via "grsec_proc_gid=" on the kernel commandline.
GRKERNSEC_TPE_UNTRUSTED_GID
Setting this GID determines what group TPE restrictions will be *enabled* for. If the sysctl option is enabled, a sysctl option with name "tpe_gid" is created.
GRKERNSEC_TPE_TRUSTED_GID
Setting this GID determines what group TPE restrictions will be *disabled* for. If the sysctl option is enabled, a sysctl option with name "tpe_gid" is created.
GRKERNSEC_SYMLINKOWN_GID
Setting this GID determines what group kernel-enforced SymlinksIfOwnerMatch will be enabled for. If the sysctl option is enabled, a sysctl option with name "symlinkown_gid" is created.
PAX
This allows you to enable various PaX features. PaX adds intrusion prevention mechanisms to the kernel that reduce the risks posed by exploitable memory corruption bugs.
PAX_SOFTMODE
Enabling this option will allow you to run PaX in soft mode, that is, PaX features will not be enforced by default, only on executables marked explicitly. You must also enable PT_PAX_FLAGS or XATTR_PAX_FLAGS support as they are the only way to mark executables for soft mode use. Soft mode can be activated by using the "pax_softmode=1" kernel command line option on boot. Furthermore you can control various PaX features at runtime via the entries in /proc/sys/kernel/pax.
PAX_EI_PAX
Enabling this option will allow you to control PaX features on a per executable basis via the 'chpax' utility available at http://pax.grsecurity.net/. The control flags will be read from an otherwise reserved part of the ELF header. This marking has numerous drawbacks (no support for soft-mode, toolchain does not know about the non-standard use of the ELF header) therefore it has been deprecated in favour of PT_PAX_FLAGS and XATTR_PAX_FLAGS support. Note that if you enable PT_PAX_FLAGS or XATTR_PAX_FLAGS marking support as well, they will override the legacy EI_PAX marks. If you enable none of the marking options then all applications will run with PaX enabled on them by default.
PAX_PT_PAX_FLAGS
Enabling this option will allow you to control PaX features on a per executable basis via the 'paxctl' utility available at http://pax.grsecurity.net/. The control flags will be read from a PaX specific ELF program header (PT_PAX_FLAGS). This marking has the benefits of supporting both soft mode and being fully integrated into the toolchain (the binutils patch is available from http://pax.grsecurity.net). Note that if you enable the legacy EI_PAX marking support as well, the EI_PAX marks will be overridden by the PT_PAX_FLAGS marks. If you enable both PT_PAX_FLAGS and XATTR_PAX_FLAGS support then you must make sure that the marks are the same if a binary has both marks. If you enable none of the marking options then all applications will run with PaX enabled on them by default.
PAX_XATTR_PAX_FLAGS
Enabling this option will allow you to control PaX features on a per executable basis via the 'setfattr' utility. The control flags will be read from the user.pax.flags extended attribute of the file. This marking has the benefit of supporting binary-only applications that self-check themselves (e.g., skype) and would not tolerate chpax/paxctl changes. The main drawback is that extended attributes are not supported by some filesystems (e.g., isofs, udf, vfat) so copying files through such filesystems will lose the extended attributes and these PaX markings. Note that if you enable the legacy EI_PAX marking support as well, the EI_PAX marks will be overridden by the XATTR_PAX_FLAGS marks. If you enable both PT_PAX_FLAGS and XATTR_PAX_FLAGS support then you must make sure that the marks are the same if a binary has both marks. If you enable none of the marking options then all applications will run with PaX enabled on them by default.
Mandatory Access Control systems have the option of controlling PaX flags on a per executable basis, choose the method supported by your particular system. - "none": if your MAC system does not interact with PaX, - "direct": if your MAC system defines pax_set_initial_flags() itself, - "hook": if your MAC system uses the pax_set_initial_flags_func callback. NOTE: this option is for developers/integrators only.
PAX_NO_ACL_FLAGS
PAX_HAVE_ACL_FLAGS
PAX_HOOK_ACL_FLAGS
PAX_NOEXEC
By design some architectures do not allow for protecting memory pages against execution or even if they do, Linux does not make use of this feature. In practice this means that if a page is readable (such as the stack or heap) it is also executable. There is a well known exploit technique that makes use of this fact and a common programming mistake where an attacker can introduce code of his choice somewhere in the attacked program's memory (typically the stack or the heap) and then execute it. If the attacked program was running with different (typically higher) privileges than that of the attacker, then he can elevate his own privilege level (e.g. get a root shell, write to files for which he does not have write access to, etc). Enabling this option will let you choose from various features that prevent the injection and execution of 'foreign' code in a program. This will also break programs that rely on the old behaviour and expect that dynamically allocated memory via the malloc() family of functions is executable (which it is not). Notable examples are the XFree86 4.x server, the java runtime and wine.
PAX_PAGEEXEC
This implementation is based on the paging feature of the CPU. On i386 without hardware non-executable bit support there is a variable but usually low performance impact, however on Intel's P4 core based CPUs it is very high so you should not enable this for kernels meant to be used on such CPUs. On alpha, avr32, ia64, parisc, sparc, sparc64, x86_64 and i386 with hardware non-executable bit support there is no performance impact, on ppc the impact is negligible. Note that several architectures require various emulations due to badly designed userland ABIs, this will cause a performance impact but will disappear as soon as userland is fixed. For example, ppc userland MUST have been built with secure-plt by a recent toolchain.
PAX_SEGMEXEC
This implementation is based on the segmentation feature of the CPU and has a very small performance impact, however applications will be limited to a 1.5 GB address space instead of the normal 3 GB.
PAX_EMUTRAMP
There are some programs and libraries that for one reason or another attempt to execute special small code snippets from non-executable memory pages. Most notable examples are the signal handler return code generated by the kernel itself and the GCC trampolines. If you enabled CONFIG_PAX_PAGEEXEC or CONFIG_PAX_SEGMEXEC then such programs will no longer work under your kernel. As a remedy you can say Y here and use the 'chpax' or 'paxctl' utilities to enable trampoline emulation for the affected programs yet still have the protection provided by the non-executable pages. On parisc you MUST enable this option and EMUSIGRT as well, otherwise your system will not even boot. Alternatively you can say N here and use the 'chpax' or 'paxctl' utilities to disable CONFIG_PAX_PAGEEXEC and CONFIG_PAX_SEGMEXEC for the affected files. NOTE: enabling this feature *may* open up a loophole in the protection provided by non-executable pages that an attacker could abuse. Therefore the best solution is to not have any files on your system that would require this option. This can be achieved by not using libc5 (which relies on the kernel signal handler return code) and not using or rewriting programs that make use of the nested function implementation of GCC. Skilled users can just fix GCC itself so that it implements nested function calls in a way that does not interfere with PaX.
PAX_EMUSIGRT
Enabling this option will have the kernel automatically detect and emulate signal return trampolines executing on the stack that would otherwise lead to task termination. This solution is intended as a temporary one for users with legacy versions of libc (libc5, glibc 2.0, uClibc before 0.9.17, Modula-3 runtime, etc) or executables linked to such, basically everything that does not specify its own SA_RESTORER function in normal executable memory like glibc 2.1+ does. On parisc you MUST enable this option, otherwise your system will not even boot. NOTE: this feature cannot be disabled on a per executable basis and since it *does* open up a loophole in the protection provided by non-executable pages, the best solution is to not have any files on your system that would require this option.
PAX_MPROTECT
Enabling this option will prevent programs from - changing the executable status of memory pages that were not originally created as executable, - making read-only executable pages writable again, - creating executable pages from anonymous memory, - making read-only-after-relocations (RELRO) data pages writable again. You should say Y here to complete the protection provided by the enforcement of non-executable pages. NOTE: you can use the 'chpax' or 'paxctl' utilities to control this feature on a per file basis.
PAX_MPROTECT_COMPAT
The current implementation of PAX_MPROTECT denies RWX allocations/mprotects by sending the proper error code to the application. For some broken userland, this can cause problems with Python or other applications. The current implementation however allows for applications like clamav to detect if JIT compilation/execution is allowed and to fall back gracefully to an interpreter-based mode if it does not. While we encourage everyone to use the current implementation as-is and push upstream to fix broken userland (note that the RWX logging option can assist with this), in some environments this may not be possible. Having to disable MPROTECT completely on certain binaries reduces the security benefit of PaX, so this option is provided for those environments to revert to the old behavior.
PAX_ELFRELOCS
Non-executable pages and mprotect() restrictions are effective in preventing the introduction of new executable code into an attacked task's address space. There remain only two venues for this kind of attack: if the attacker can execute already existing code in the attacked task then he can either have it create and mmap() a file containing his code or have it mmap() an already existing ELF library that does not have position independent code in it and use mprotect() on it to make it writable and copy his code there. While protecting against the former approach is beyond PaX, the latter can be prevented by having only PIC ELF libraries on one's system (which do not need to relocate their code). If you are sure this is your case, as is the case with all modern Linux distributions, then leave this option disabled. You should say 'n' here.
PAX_ETEXECRELOCS
On some architectures there are incorrectly created applications that require text relocations and would not work without enabling this option. If you are an alpha, ia64 or parisc user, you should enable this option and disable it once you have made sure that none of your applications need it.
PAX_EMUPLT
Enabling this option will have the kernel automatically detect and emulate the Procedure Linkage Table entries in ELF files. On some architectures such entries are in writable memory, and become non-executable leading to task termination. Therefore it is mandatory that you enable this option on alpha, parisc, sparc and sparc64, otherwise your system would not even boot. NOTE: this feature *does* open up a loophole in the protection provided by the non-executable pages, therefore the proper solution is to modify the toolchain to produce a PLT that does not need to be writable.
PAX_DLRESOLVE
This option is needed if userland has an old glibc (before 2.4) that puts a 'save' instruction into the runtime generated resolver stub that needs special emulation.
PAX_KERNEXEC
This is the kernel land equivalent of PAGEEXEC and MPROTECT, that is, enabling this option will make it harder to inject and execute 'foreign' code in kernel memory itself.
Select the method used to instrument function pointer dereferences. Note that binary modules cannot be instrumented by this approach. Note that the implementation requires a gcc with plugin support, i.e., gcc 4.5 or newer. You may need to install the supporting headers explicitly in addition to the normal gcc package.
PAX_KERNEXEC_PLUGIN_METHOD_BTS
This method is compatible with binary only modules but has a higher runtime overhead.
PAX_KERNEXEC_PLUGIN_METHOD
PAX_KERNEXEC_MODULE_TEXT
Due to implementation details the kernel must reserve a fixed amount of memory for runtime allocated code (such as modules) at compile time that cannot be changed at runtime. Here you can specify the minimum amount in MB that will be reserved. Due to the same implementation details this size will always be rounded up to the next 2/4 MB boundary (depends on PAE) so the actually available memory for runtime allocated code will usually be more than this minimum. The default 4 MB should be enough for most users but if you have an excessive number of modules (e.g., most distribution configs compile many drivers as modules) or use huge modules such as nvidia's kernel driver, you will need to adjust this amount. A good rule of thumb is to look at your currently loaded kernel modules and add up their sizes.
PAX_ASLR
Many if not most exploit techniques rely on the knowledge of certain addresses in the attacked program. The following options will allow the kernel to apply a certain amount of randomization to specific parts of the program thereby forcing an attacker to guess them in most cases. Any failed guess will most likely crash the attacked program which allows the kernel to detect such attempts and react on them. PaX itself provides no reaction mechanisms, instead it is strongly encouraged that you make use of Nergal's segvguard (ftp://ftp.pl.openwall.com/misc/segvguard/) or grsecurity's (http://www.grsecurity.net/) built-in crash detection features or develop one yourself. By saying Y here you can choose to randomize the following areas: - top of the task's kernel stack - top of the task's userland stack - base address for mmap() requests that do not specify one (this includes all libraries) - base address of the main executable It is strongly recommended to say Y here as address space layout randomization has negligible impact on performance yet it provides a very effective protection. NOTE: you can use the 'chpax' or 'paxctl' utilities to control this feature on a per file basis.
PAX_RANDKSTACK
By saying Y here the kernel will randomize every task's kernel stack on every system call. This will not only force an attacker to guess it but also prevent him from making use of possible leaked information about it. Since the kernel stack is a rather scarce resource, randomization may cause unexpected stack overflows, therefore you should very carefully test your system. Note that once enabled in the kernel configuration, this feature cannot be disabled on a per file basis.
PAX_RANDUSTACK
By saying Y here the kernel will randomize every task's userland stack. The randomization is done in two steps where the second one may apply a big amount of shift to the top of the stack and cause problems for programs that want to use lots of memory (more than 2.5 GB if SEGMEXEC is not active, or 1.25 GB when it is). For this reason the second step can be controlled by 'chpax' or 'paxctl' on a per file basis.
PAX_RANDMMAP
By saying Y here the kernel will use a randomized base address for mmap() requests that do not specify one themselves. As a result all dynamically loaded libraries will appear at random addresses and therefore be harder to exploit by a technique where an attacker attempts to execute library code for his purposes (e.g. spawn a shell from an exploited program that is running at an elevated privilege level). Furthermore, if a program is relinked as a dynamic ELF file, its base address will be randomized as well, completing the full randomization of the address space layout. Attacking such programs becomes a guess game. You can find an example of doing this at http://pax.grsecurity.net/et_dyn.tar.gz and practical samples at http://www.grsecurity.net/grsec-gcc-specs.tar.gz . NOTE: you can use the 'chpax' or 'paxctl' utilities to control this feature on a per file basis.
PAX_MEMORY_SANITIZE
By saying Y here the kernel will erase memory pages and slab objects as soon as they are freed. This in turn reduces the lifetime of data stored in them, making it less likely that sensitive information such as passwords, cryptographic secrets, etc stay in memory for too long. This is especially useful for programs whose runtime is short, long lived processes and the kernel itself benefit from this as long as they ensure timely freeing of memory that may hold sensitive information. A nice side effect of the sanitization of slab objects is the reduction of possible info leaks caused by padding bytes within the leaky structures. Use-after-free bugs for structures containing pointers can also be detected as dereferencing the sanitized pointer will generate an access violation. The tradeoff is performance impact, on a single CPU system kernel compilation sees a 3% slowdown, other systems and workloads may vary and you are advised to test this feature on your expected workload before deploying it. To reduce the performance penalty by sanitizing pages only, albeit limiting the effectiveness of this feature at the same time, slab sanitization can be disabled with the kernel commandline parameter "pax_sanitize_slab=0". Note that this feature does not protect data stored in live pages, e.g., process memory swapped to disk may stay there for a long time.
PAX_MEMORY_STACKLEAK
By saying Y here the kernel will erase the kernel stack before it returns from a system call. This in turn reduces the information that a kernel stack leak bug can reveal. Note that such a bug can still leak information that was put on the stack by the current system call (the one eventually triggering the bug) but traces of earlier system calls on the kernel stack cannot leak anymore. The tradeoff is performance impact: on a single CPU system kernel compilation sees a 1% slowdown, other systems and workloads may vary and you are advised to test this feature on your expected workload before deploying it. Note that the full feature requires a gcc with plugin support, i.e., gcc 4.5 or newer. You may need to install the supporting headers explicitly in addition to the normal gcc package. Using older gcc versions means that functions with large enough stack frames may leave uninitialized memory behind that may be exposed to a later syscall leaking the stack.
PAX_MEMORY_STRUCTLEAK
By saying Y here the kernel will zero initialize some local variables that are going to be copied to userland. This in turn prevents unintended information leakage from the kernel stack should later code forget to explicitly set all parts of the copied variable. The tradeoff is less performance impact than PAX_MEMORY_STACKLEAK at a much smaller coverage. Note that the implementation requires a gcc with plugin support, i.e., gcc 4.5 or newer. You may need to install the supporting headers explicitly in addition to the normal gcc package.
PAX_MEMORY_UDEREF
By saying Y here the kernel will be prevented from dereferencing userland pointers in contexts where the kernel expects only kernel pointers. This is both a useful runtime debugging feature and a security measure that prevents exploiting a class of kernel bugs. The tradeoff is that some virtualization solutions may experience a huge slowdown and therefore you should not enable this feature for kernels meant to run in such environments. Whether a given VM solution is affected or not is best determined by simply trying it out, the performance impact will be obvious right on boot as this mechanism engages from very early on. A good rule of thumb is that VMs running on CPUs without hardware virtualization support (i.e., the majority of IA-32 CPUs) will likely experience the slowdown. On X86_64 the kernel will make use of PCID support when available (Intel's Westmere, Sandy Bridge, etc) for better security (default) or performance impact. Pass pax_weakuderef on the kernel command line to choose the latter.
PAX_REFCOUNT
By saying Y here the kernel will detect and prevent overflowing various (but not all) kinds of object reference counters. Such overflows can normally occur due to bugs only and are often, if not always, exploitable. The tradeoff is that data structures protected by an overflowed refcount will never be freed and therefore will leak memory. Note that this leak also happens even without this protection but in that case the overflow can eventually trigger the freeing of the data structure while it is still being used elsewhere, resulting in the exploitable situation that this feature prevents. Since this has a negligible performance impact, you should enable this feature.
PAX_CONSTIFY_PLUGIN
By saying Y here the compiler will automatically constify a class of types that contain only function pointers. This reduces the kernel's attack surface and also produces a better memory layout. Note that the implementation requires a gcc with plugin support, i.e., gcc 4.5 or newer. You may need to install the supporting headers explicitly in addition to the normal gcc package. Note that if some code really has to modify constified variables then the source code will have to be patched to allow it. Examples can be found in PaX itself (the no_const attribute) and for some out-of-tree modules at http://www.grsecurity.net/~paxguy1/ .
PAX_USERCOPY
By saying Y here the kernel will enforce the size of heap objects when they are copied in either direction between the kernel and userland, even if only a part of the heap object is copied. Specifically, this checking prevents information leaking from the kernel heap during kernel to userland copies (if the kernel heap object is otherwise fully initialized) and prevents kernel heap overflows during userland to kernel copies. Note that the current implementation provides the strictest bounds checks for the SLUB allocator. Enabling this option also enables per-slab cache protection against data in a given cache being copied into/out of via userland accessors. Though the whitelist of regions will be reduced over time, it notably protects important data structures like task structs. If frame pointers are enabled on x86, this option will also restrict copies into and out of the kernel stack to local variables within a single frame. Since this has a negligible performance impact, you should enable this feature.
PAX_SIZE_OVERFLOW
By saying Y here the kernel recomputes expressions of function arguments marked by a size_overflow attribute with double integer precision (DImode/TImode for 32/64 bit integer types). The recomputed argument is checked against TYPE_MAX and an event is logged on overflow and the triggering process is killed. Homepage: http://www.grsecurity.net/~ephox/overflow_plugin/ Note that the implementation requires a gcc with plugin support, i.e., gcc 4.5 or newer. You may need to install the supporting headers explicitly in addition to the normal gcc package.
PAX_LATENT_ENTROPY
By saying Y here the kernel will instrument some kernel code to extract some entropy from both original and artificially created program state. This will help especially embedded systems where there is little 'natural' source of entropy normally. The cost is some slowdown of the boot process and fork and irq processing. When pax_extra_latent_entropy is passed on the kernel command line, entropy will be extracted from up to the first 4GB of RAM while the runtime memory allocator is being initialized. This costs even more slowdown of the boot process. Note that the implementation requires a gcc with plugin support, i.e., gcc 4.5 or newer. You may need to install the supporting headers explicitly in addition to the normal gcc package. Note that entropy extracted this way is not cryptographically secure!
PAX_RAP
By saying Y here the kernel will check indirect control transfers in order to detect and prevent attacks that try to hijack control flow by overwriting code pointers. Note that the implementation requires a gcc with plugin support, i.e., gcc 4.5 or newer. You may need to install the supporting headers explicitly in addition to the normal gcc package.
GRKERNSEC_KMEM
If you say Y here, /dev/kmem and /dev/mem won't be allowed to be written to or read from to modify or leak the contents of the running kernel. /dev/port will also not be allowed to be opened, and support for /dev/cpu/*/msr and kexec will be removed. If you have module support disabled, enabling this will close up six ways that are currently used to insert malicious code into the running kernel. Even with this feature enabled, we still highly recommend that you use the RBAC system, as it is still possible for an attacker to modify the running kernel through other more obscure methods. Enabling this feature will prevent the "cpupower" and "powertop" tools from working. It is highly recommended that you say Y here if you meet all the conditions above.
GRKERNSEC_VM86
If you say Y here, only processes with CAP_SYS_RAWIO will be able to make use of a special execution mode on 32bit x86 processors called Virtual 8086 (VM86) mode. XFree86 may need vm86 mode for certain video cards and will still work with this option enabled. The purpose of the option is to prevent exploitation of emulation errors in virtualization of vm86 mode like the one discovered in VMWare in 2009. Nearly all users should be able to enable this option.
GRKERNSEC_IO
相关 sysctl 变量
- kernel.grsecurity.disable_priv_io
If you say Y here, all ioperm and iopl calls will return an error. Ioperm and iopl can be used to modify the running kernel. Unfortunately, some programs need this access to operate properly, the most notable of which are XFree86 and hwclock. hwclock can be remedied by having RTC support in the kernel, so real-time clock support is enabled if this option is enabled, to ensure that hwclock operates correctly. If you're using XFree86 or a version of Xorg from 2012 or earlier, you may not be able to boot into a graphical environment with this option enabled. In this case, you should use the RBAC system instead.
GRKERNSEC_JIT_HARDEN
If you say Y here, the native code generated by the kernel's Berkeley Packet Filter (BPF) JIT engine will be hardened against JIT-spraying attacks that attempt to fit attacker-beneficial instructions in 32bit immediate fields of JIT-generated native instructions. The attacker will generally aim to cause an unintended instruction sequence of JIT-generated native code to execute by jumping into the middle of a generated instruction. This feature effectively randomizes the 32bit immediate constants present in the generated code to thwart such attacks. If you're using KERNEXEC, it's recommended that you enable this option to supplement the hardening of the kernel.
GRKERNSEC_PERF_HARDEN
If you say Y here, the range of acceptable values for the /proc/sys/kernel/perf_event_paranoid sysctl will be expanded to allow and default to a new value: 3. When the sysctl is set to this value, no unprivileged use of the PERF_EVENTS syscall interface will be permitted. Though PERF_EVENTS can be used legitimately for performance monitoring and low-level application profiling, it is forced on regardless of configuration, has been at fault for several vulnerabilities, and creates new opportunities for side channels and other information leaks. This feature puts PERF_EVENTS into a secure default state and permits the administrator to change out of it temporarily if unprivileged application profiling is needed.
GRKERNSEC_RAND_THREADSTACK
If you say Y here, a random-sized gap will be enforced between allocated thread stacks. Glibc's NPTL and other threading libraries that pass MAP_STACK to the kernel for thread stack allocation are supported. The implementation currently provides 8 bits of entropy for the gap. Many distributions do not compile threaded remote services with the -fstack-check argument to GCC, causing the variable-sized stack-based allocator, alloca(), to not probe the stack on allocation. This permits an unbounded alloca() to skip over any guard page and potentially modify another thread's stack reliably. An enforced random gap reduces the reliability of such an attack and increases the chance that such a read/write to another thread's stack instead lands in an unmapped area, causing a crash and triggering grsecurity's anti-bruteforcing logic.
GRKERNSEC_PROC_MEMMAP
If you say Y here, the /proc/<pid>/maps and /proc/<pid>/stat files will give no information about the addresses of its mappings if PaX features that rely on random addresses are enabled on the task. In addition to sanitizing this information and disabling other dangerous sources of information, this option causes reads of sensitive /proc/<pid> entries where the file descriptor was opened in a different task than the one performing the read. Such attempts are logged. This option also limits argv/env strings for suid/sgid binaries to 512KB to prevent a complete exhaustion of the stack entropy provided by ASLR. Finally, it places an 8MB stack resource limit on suid/sgid binaries to prevent alternative mmap layouts from being abused. If you use PaX it is essential that you say Y here as it closes up several holes that make full ASLR useless locally.
GRKERNSEC_KSTACKOVERFLOW
If you say Y here, the kernel's process stacks will be allocated with vmalloc instead of the kernel's default allocator. This introduces guard pages that in combination with the alloca checking of the STACKLEAK feature prevents all forms of kernel process stack overflow abuse. Note that this is different from kernel stack buffer overflows.
GRKERNSEC_BRUTE
相关 sysctl 变量
- kernel.grsecurity.deter_bruteforce
If you say Y here, attempts to bruteforce exploits against forking daemons such as Apache or sshd, as well as against suid/sgid binaries will be deterred. When a child of a forking daemon is killed by PaX or crashes due to an illegal instruction or other suspicious signal, the parent process will be delayed 30 seconds upon every subsequent fork until the administrator is able to assess the situation and restart the daemon. In the suid/sgid case, the attempt is logged, the user has all their existing instances of the suid/sgid binary terminated and will be unable to execute any suid/sgid binaries for 15 minutes. It is recommended that you also enable signal logging in the auditing section so that logs are generated when a process triggers a suspicious signal. If the sysctl option is enabled, a sysctl option with name "deter_bruteforce" is created.
GRKERNSEC_MODHARDEN
If you say Y here, module auto-loading in response to use of some feature implemented by an unloaded module will be restricted to root users. Enabling this option helps defend against attacks by unprivileged users who abuse the auto-loading behavior to cause a vulnerable module to load that is then exploited. If this option prevents a legitimate use of auto-loading for a non-root user, the administrator can execute modprobe manually with the exact name of the module mentioned in the alert log. Alternatively, the administrator can add the module to the list of modules loaded at boot by modifying init scripts. Modification of init scripts will most likely be needed on Ubuntu servers with encrypted home directory support enabled, as the first non-root user logging in will cause the ecb(aes), ecb(aes)-all, cbc(aes), and cbc(aes)-all modules to be loaded.
GRKERNSEC_HIDESYM
If you say Y here, getting information on loaded modules, and displaying all kernel symbols through a syscall will be restricted to users with CAP_SYS_MODULE. For software compatibility reasons, /proc/kallsyms will be restricted to the root user. The RBAC system can hide that entry even from root. This option also prevents leaking of kernel addresses through several /proc entries. Note that this option is only effective provided the following conditions are met: 1) The kernel using grsecurity is not precompiled by some distribution 2) You have also enabled GRKERNSEC_DMESG 3) You are using the RBAC system and hiding other files such as your kernel image and System.map. Alternatively, enabling this option causes the permissions on /boot, /lib/modules, and the kernel source directory to change at compile time to prevent reading by non-root users. If the above conditions are met, this option will aid in providing a useful protection against local kernel exploitation of overflows and arbitrary read/write vulnerabilities. It is highly recommended that you enable GRKERNSEC_PERF_HARDEN in addition to this feature.
GRKERNSEC_RANDSTRUCT
If you say Y here, the layouts of a number of sensitive kernel structures (task, fs, cred, etc) and all structures composed entirely of function pointers (aka "ops" structs) will be randomized at compile-time. This can introduce the requirement of an additional infoleak vulnerability for exploits targeting these structure types. Enabling this feature will introduce some performance impact, slightly increase memory usage, and prevent the use of forensic tools like Volatility against the system (unless the kernel source tree isn't cleaned after kernel installation). The seed used for compilation is located at tools/gcc/randomize_layout_seed.h. It remains after a make clean to allow for external modules to be compiled with the existing seed and will be removed by a make mrproper or make distclean.
GRKERNSEC_RANDSTRUCT_PERFORMANCE
If you say Y here, the RANDSTRUCT randomization will make a best effort at restricting randomization to cacheline-sized groups of elements. It will further not randomize bitfields in structures. This reduces the performance hit of RANDSTRUCT at the cost of weakened randomization.
GRKERNSEC_KERN_LOCKOUT
If you say Y here, when a PaX alert is triggered due to suspicious activity in the kernel (from KERNEXEC/UDEREF/USERCOPY) or an OOPS occurs due to bad memory accesses, instead of just terminating the offending process (and potentially allowing a subsequent exploit from the same user), we will take one of two actions: If the user was root, we will panic the system If the user was non-root, we will log the attempt, terminate all processes owned by the user, then prevent them from creating any new processes until the system is restarted This deters repeated kernel exploitation/bruteforcing attempts and is useful for later forensics.
GRKERNSEC_OLD_ARM_USERLAND
If you say Y here, stubs of executable code to perform such operations as "compare-exchange" will be placed at fixed locations in the ARM vector table. This is unfortunately needed for old ARM userland meant to run across a wide range of processors. Without this option enabled, the get_tls and data memory barrier stubs will be emulated by the kernel, which is enough for Linaro userlands or other userlands designed for v6 and newer ARM CPUs. It's recommended that you try without this option enabled first, and only enable it if your userland does not boot (it will likely fail at init time).
GRKERNSEC_NO_RBAC
If you say Y here, the /dev/grsec device will be removed from the kernel, preventing the RBAC system from being enabled. You should only say Y here if you have no intention of using the RBAC system, so as to prevent an attacker with root access from misusing the RBAC system to hide files and processes when loadable module support and /dev/[k]mem have been locked down.
GRKERNSEC_ACL_HIDEKERN
If you say Y here, all kernel threads will be hidden to all processes but those whose subject has the "view hidden processes" flag.
GRKERNSEC_ACL_MAXTRIES
This option enforces the maximum number of times a user can attempt to authorize themselves with the grsecurity RBAC system before being denied the ability to attempt authorization again for a specified time. The lower the number, the harder it will be to brute-force a password.
GRKERNSEC_ACL_TIMEOUT
This option specifies the time the user must wait after attempting to authorize to the RBAC system with the maximum number of invalid passwords. The higher the number, the harder it will be to brute-force a password.
GRKERNSEC_PROC
If you say Y here, the permissions of the /proc filesystem will be altered to enhance system security and privacy. You MUST choose either a user only restriction or a user and group restriction. Depending upon the option you choose, you can either restrict users to see only the processes they themselves run, or choose a group that can view all processes and files normally restricted to root if you choose the "restrict to user only" option. NOTE: If you're running identd or ntpd as a non-root user, you will have to run it as the group you specify here.
GRKERNSEC_PROC_USER
If you say Y here, non-root users will only be able to view their own processes, and restricts them from viewing network-related information, and viewing kernel symbol and module information.
GRKERNSEC_PROC_USERGROUP
If you say Y here, you will be able to select a group that will be able to view all processes and network-related information. If you've enabled GRKERNSEC_HIDESYM, kernel and symbol information may still remain hidden. This option is useful if you want to run identd as a non-root user. The group you select may also be chosen at boot time via "grsec_proc_gid=" on the kernel commandline.
GRKERNSEC_PROC_GID
Setting this GID determines which group will be exempted from grsecurity's /proc restrictions, allowing users of the specified group to view network statistics and the existence of other users' processes on the system. This GID may also be chosen at boot time via "grsec_proc_gid=" on the kernel commandline.
GRKERNSEC_PROC_ADD
If you say Y here, additional restrictions will be placed on /proc that keep normal users from viewing device information and slabinfo information that could be useful for exploits.
GRKERNSEC_LINK
相关 sysctl 变量
- kernel.grsecurity.linking_restrictions
If you say Y here, /tmp race exploits will be prevented, since users will no longer be able to follow symlinks owned by other users in world-writable +t directories (e.g. /tmp), unless the owner of the symlink is the owner of the directory. users will also not be able to hardlink to files they do not own. If the sysctl option is enabled, a sysctl option with name "linking_restrictions" is created.
GRKERNSEC_SYMLINKOWN
相关 sysctl 变量
- kernel.grsecurity.enforce_symlinksifowner
- kernel.grsecurity.symlinkown_gid
Apache's SymlinksIfOwnerMatch option has an inherent race condition that prevents it from being used as a security feature. As Apache verifies the symlink by performing a stat() against the target of the symlink before it is followed, an attacker can setup a symlink to point to a same-owned file, then replace the symlink with one that targets another user's file just after Apache "validates" the symlink -- a classic TOCTOU race. If you say Y here, a complete, race-free replacement for Apache's "SymlinksIfOwnerMatch" option will be in place for the group you specify. If the sysctl option is enabled, a sysctl option with name "enforce_symlinksifowner" is created.
GRKERNSEC_SYMLINKOWN_GID
Setting this GID determines what group kernel-enforced SymlinksIfOwnerMatch will be enabled for. If the sysctl option is enabled, a sysctl option with name "symlinkown_gid" is created.
GRKERNSEC_FIFO
相关 sysctl 变量
- kernel.grsecurity.fifo_restrictions
If you say Y here, users will not be able to write to FIFOs they don't own in world-writable +t directories (e.g. /tmp), unless the owner of the FIFO is the same owner of the directory it's held in. If the sysctl option is enabled, a sysctl option with name "fifo_restrictions" is created.
GRKERNSEC_SYSFS_RESTRICT
If you say Y here, sysfs (the pseudo-filesystem mounted at /sys) and any filesystem normally mounted under it (e.g. debugfs) will be mostly accessible only by root. These filesystems generally provide access to hardware and debug information that isn't appropriate for unprivileged users of the system. Sysfs and debugfs have also become a large source of new vulnerabilities, ranging from infoleaks to local compromise. There has been very little oversight with an eye toward security involved in adding new exporters of information to these filesystems, so their use is discouraged. For reasons of compatibility, a few directories have been whitelisted for access by non-root users: /sys/fs/selinux /sys/fs/fuse /sys/devices/system/cpu
GRKERNSEC_ROFS
相关 sysctl 变量
- kernel.grsecurity.romount_protect
If you say Y here, a sysctl option with name "romount_protect" will be created. By setting this option to 1 at runtime, filesystems will be protected in the following ways: * No new writable mounts will be allowed * Existing read-only mounts won't be able to be remounted read/write * Write operations will be denied on all block devices This option acts independently of grsec_lock: once it is set to 1, it cannot be turned off. Therefore, please be mindful of the resulting behavior if this option is enabled in an init script on a read-only filesystem. Also be aware that as with other root-focused features, GRKERNSEC_KMEM and GRKERNSEC_IO should be enabled and module loading disabled via config or at runtime. This feature is mainly intended for secure embedded systems.
GRKERNSEC_DEVICE_SIDECHANNEL
If you say Y here, timing analyses on block or character devices like /dev/ptmx using stat or inotify/dnotify/fanotify will be thwarted for unprivileged users. If a process without CAP_MKNOD stats such a device, the last access and last modify times will match the device's create time. No access or modify events will be triggered through inotify/dnotify/fanotify for such devices. This feature will prevent attacks that may at a minimum allow an attacker to determine the administrator's password length.
GRKERNSEC_CHROOT
If you say Y here, you will be able to choose several options that will make breaking out of a chrooted jail much more difficult. If you encounter no software incompatibilities with the following options, it is recommended that you enable each one.
GRKERNSEC_CHROOT_MOUNT
相关 sysctl 变量
- kernel.grsecurity.chroot_deny_mount
If you say Y here, processes inside a chroot will not be able to mount or remount filesystems. If the sysctl option is enabled, a sysctl option with name "chroot_deny_mount" is created.
GRKERNSEC_CHROOT_DOUBLE
相关 sysctl 变量
- kernel.grsecurity.chroot_deny_chroot
If you say Y here, processes inside a chroot will not be able to chroot again outside the chroot. This is a widely used method of breaking out of a chroot jail and should not be allowed. If the sysctl option is enabled, a sysctl option with name "chroot_deny_chroot" is created.
GRKERNSEC_CHROOT_PIVOT
相关 sysctl 变量
- kernel.grsecurity.chroot_deny_pivot
If you say Y here, processes inside a chroot will not be able to use a function called pivot_root() that was introduced in Linux 2.3.41. It works similar to chroot in that it changes the root filesystem. This function could be misused in a chrooted process to attempt to break out of the chroot, and therefore should not be allowed. If the sysctl option is enabled, a sysctl option with name "chroot_deny_pivot" is created.
GRKERNSEC_CHROOT_CHDIR
相关 sysctl 变量
- kernel.grsecurity.chroot_enforce_chdir
If you say Y here, the current working directory of all newly-chrooted applications will be set to the root directory of the chroot. The man page on chroot(2) states: Note that usually chhroot does not change the current working directory, so that `.' can be outside the tree rooted at `/'. In particular, the super-user can escape from a `chroot jail' by doing `mkdir foo; chroot foo; cd ..'. It is recommended that you say Y here, since it's not known to break any software. If the sysctl option is enabled, a sysctl option with name "chroot_enforce_chdir" is created.
GRKERNSEC_CHROOT_CHMOD
相关 sysctl 变量
- kernel.grsecurity.chroot_deny_chmod
If you say Y here, processes inside a chroot will not be able to chmod or fchmod files to make them have suid or sgid bits. This protects against another published method of breaking a chroot. If the sysctl option is enabled, a sysctl option with name "chroot_deny_chmod" is created.
GRKERNSEC_CHROOT_FCHDIR
相关 sysctl 变量
- kernel.grsecurity.chroot_deny_fchdir
If you say Y here, a well-known method of breaking chroots by fchdir'ing to a file descriptor of the chrooting process that points to a directory outside the filesystem will be stopped. If the sysctl option is enabled, a sysctl option with name "chroot_deny_fchdir" is created.
GRKERNSEC_CHROOT_MKNOD
相关 sysctl 变量
- kernel.grsecurity.chroot_deny_mknod
If you say Y here, processes inside a chroot will not be allowed to mknod. The problem with using mknod inside a chroot is that it would allow an attacker to create a device entry that is the same as one on the physical root of your system, which could range from anything from the console device to a device for your harddrive (which they could then use to wipe the drive or steal data). It is recommended that you say Y here, unless you run into software incompatibilities. If the sysctl option is enabled, a sysctl option with name "chroot_deny_mknod" is created.
GRKERNSEC_CHROOT_SHMAT
相关 sysctl 变量
- kernel.grsecurity.chroot_deny_shmat
If you say Y here, processes inside a chroot will not be able to attach to shared memory segments that were created outside of the chroot jail. It is recommended that you say Y here. If the sysctl option is enabled, a sysctl option with name "chroot_deny_shmat" is created.
GRKERNSEC_CHROOT_UNIX
相关 sysctl 变量
- kernel.grsecurity.chroot_deny_unix
If you say Y here, processes inside a chroot will not be able to connect to abstract (meaning not belonging to a filesystem) Unix domain sockets that were bound outside of a chroot. It is recommended that you say Y here. If the sysctl option is enabled, a sysctl option with name "chroot_deny_unix" is created.
GRKERNSEC_CHROOT_FINDTASK
相关 sysctl 变量
- kernel.grsecurity.chroot_findtask
If you say Y here, processes inside a chroot will not be able to kill, send signals with fcntl, ptrace, capget, getpgid, setpgid, getsid, or view any process outside of the chroot. If the sysctl option is enabled, a sysctl option with name "chroot_findtask" is created.
GRKERNSEC_CHROOT_NICE
相关 sysctl 变量
- kernel.grsecurity.chroot_restrict_nice
If you say Y here, processes inside a chroot will not be able to raise the priority of processes in the chroot, or alter the priority of processes outside the chroot. This provides more security than simply removing CAP_SYS_NICE from the process' capability set. If the sysctl option is enabled, a sysctl option with name "chroot_restrict_nice" is created.
GRKERNSEC_CHROOT_SYSCTL
相关 sysctl 变量
- kernel.grsecurity.chroot_deny_sysctl
If you say Y here, an attacker in a chroot will not be able to write to sysctl entries, either by sysctl(2) or through a /proc interface. It is strongly recommended that you say Y here. If the sysctl option is enabled, a sysctl option with name "chroot_deny_sysctl" is created.
GRKERNSEC_CHROOT_CAPS
相关 sysctl 变量
- kernel.grsecurity.chroot_caps
If you say Y here, the capabilities on all processes within a chroot jail will be lowered to stop module insertion, raw i/o, system and net admin tasks, rebooting the system, modifying immutable files, modifying IPC owned by another, and changing the system time. This is left an option because it can break some apps. Disable this if your chrooted apps are having problems performing those kinds of tasks. If the sysctl option is enabled, a sysctl option with name "chroot_caps" is created.
GRKERNSEC_CHROOT_INITRD
If you say Y here, tasks started prior to init will be exempted from grsecurity's chroot restrictions. This option is mainly meant to resolve Plymouth's performing privileged operations unnecessarily in a chroot.
GRKERNSEC_AUDIT_GROUP
相关 sysctl 变量
- kernel.grsecurity.audit_gid
- kernel.grsecurity.audit_group
If you say Y here, the exec and chdir logging features will only operate on a group you specify. This option is recommended if you only want to watch certain users instead of having a large amount of logs from the entire system. If the sysctl option is enabled, a sysctl option with name "audit_group" is created.
GRKERNSEC_AUDIT_GID
GRKERNSEC_EXECLOG
相关 sysctl 变量
- kernel.grsecurity.exec_logging
If you say Y here, all execve() calls will be logged (since the other exec*() calls are frontends to execve(), all execution will be logged). Useful for shell-servers that like to keep track of their users. If the sysctl option is enabled, a sysctl option with name "exec_logging" is created. WARNING: This option when enabled will produce a LOT of logs, especially on an active system.
GRKERNSEC_RESLOG
相关 sysctl 变量
- kernel.grsecurity.resource_logging
If you say Y here, all attempts to overstep resource limits will be logged with the resource name, the requested size, and the current limit. It is highly recommended that you say Y here. If the sysctl option is enabled, a sysctl option with name "resource_logging" is created. If the RBAC system is enabled, the sysctl value is ignored.
GRKERNSEC_CHROOT_EXECLOG
相关 sysctl 变量
- kernel.grsecurity.chroot_execlog
If you say Y here, all executions inside a chroot jail will be logged to syslog. This can cause a large amount of logs if certain applications (e.g. djb's daemontools) are installed on the system, and is therefore left as an option. If the sysctl option is enabled, a sysctl option with name "chroot_execlog" is created.
GRKERNSEC_AUDIT_PTRACE
相关 sysctl 变量
- kernel.grsecurity.audit_ptrace
If you say Y here, all attempts to attach to a process via ptrace will be logged. If the sysctl option is enabled, a sysctl option with name "audit_ptrace" is created.
GRKERNSEC_AUDIT_CHDIR
相关 sysctl 变量
- kernel.grsecurity.audit_chdir
If you say Y here, all chdir() calls will be logged. If the sysctl option is enabled, a sysctl option with name "audit_chdir" is created.
GRKERNSEC_AUDIT_MOUNT
相关 sysctl 变量
- kernel.grsecurity.audit_mount
If you say Y here, all mounts and unmounts will be logged. If the sysctl option is enabled, a sysctl option with name "audit_mount" is created.
GRKERNSEC_SIGNAL
相关 sysctl 变量
- kernel.grsecurity.signal_logging
If you say Y here, certain important signals will be logged, such as SIGSEGV, which will as a result inform you of when a error in a program occurred, which in some cases could mean a possible exploit attempt. If the sysctl option is enabled, a sysctl option with name "signal_logging" is created.
GRKERNSEC_FORKFAIL
相关 sysctl 变量
- kernel.grsecurity.forkfail_logging
If you say Y here, all failed fork() attempts will be logged. This could suggest a fork bomb, or someone attempting to overstep their process limit. If the sysctl option is enabled, a sysctl option with name "forkfail_logging" is created.
GRKERNSEC_TIME
相关 sysctl 变量
- kernel.grsecurity.timechange_logging
If you say Y here, any changes of the system clock will be logged. If the sysctl option is enabled, a sysctl option with name "timechange_logging" is created.
GRKERNSEC_PROC_IPADDR
If you say Y here, a new entry will be added to each /proc/<pid> directory that contains the IP address of the person using the task. The IP is carried across local TCP and AF_UNIX stream sockets. This information can be useful for IDS/IPSes to perform remote response to a local attack. The entry is readable by only the owner of the process (and root if he has CAP_DAC_OVERRIDE, which can be removed via the RBAC system), and thus does not create privacy concerns.
GRKERNSEC_RWXMAP_LOG
相关 sysctl 变量
- kernel.grsecurity.rwxmap_logging
If you say Y here, calls to mmap() and mprotect() with explicit usage of PROT_WRITE and PROT_EXEC together will be logged when denied by the PAX_MPROTECT feature. This feature will also log other problematic scenarios that can occur when PAX_MPROTECT is enabled on a binary, like textrels and PT_GNU_STACK. If the sysctl option is enabled, a sysctl option with name "rwxmap_logging" is created.
GRKERNSEC_DMESG
相关 sysctl 变量
- kernel.grsecurity.dmesg
If you say Y here, non-root users will not be able to use dmesg(8) to view the contents of the kernel's circular log buffer. The kernel's log buffer often contains kernel addresses and other identifying information useful to an attacker in fingerprinting a system for a targeted exploit. If the sysctl option is enabled, a sysctl option with name "dmesg" is created.
GRKERNSEC_HARDEN_PTRACE
相关 sysctl 变量
- kernel.grsecurity.harden_ptrace
If you say Y here, TTY sniffers and other malicious monitoring programs implemented through ptrace will be defeated. If you have been using the RBAC system, this option has already been enabled for several years for all users, with the ability to make fine-grained exceptions. This option only affects the ability of non-root users to ptrace processes that are not a descendent of the ptracing process. This means that strace ./binary and gdb ./binary will still work, but attaching to arbitrary processes will not. If the sysctl option is enabled, a sysctl option with name "harden_ptrace" is created.
GRKERNSEC_PTRACE_READEXEC
相关 sysctl 变量
- kernel.grsecurity.ptrace_readexec
If you say Y here, unprivileged users will not be able to ptrace unreadable binaries. This option is useful in environments that remove the read bits (e.g. file mode 4711) from suid binaries to prevent infoleaking of their contents. This option adds consistency to the use of that file mode, as the binary could normally be read out when run without privileges while ptracing. If the sysctl option is enabled, a sysctl option with name "ptrace_readexec" is created.
GRKERNSEC_SETXID
相关 sysctl 变量
- kernel.grsecurity.consistent_setxid
If you say Y here, a change from a root uid to a non-root uid in a multithreaded application will cause the resulting uids, gids, supplementary groups, and capabilities in that thread to be propagated to the other threads of the process. In most cases this is unnecessary, as glibc will emulate this behavior on behalf of the application. Other libcs do not act in the same way, allowing the other threads of the process to continue running with root privileges. If the sysctl option is enabled, a sysctl option with name "consistent_setxid" is created.
GRKERNSEC_HARDEN_IPC
相关 sysctl 变量
- kernel.grsecurity.harden_ipc
If you say Y here, access to overly-permissive IPC objects (shared memory, message queues, and semaphores) will be denied for processes given the following criteria beyond normal permission checks: 1) If the IPC object is world-accessible and the euid doesn't match that of the creator or current uid for the IPC object 2) If the IPC object is group-accessible and the egid doesn't match that of the creator or current gid for the IPC object It's a common error to grant too much permission to these objects, with impact ranging from denial of service and information leaking to privilege escalation. This feature was developed in response to research by Tim Brown: http://labs.portcullis.co.uk/whitepapers/memory-squatting-attacks-on-system-v-shared-memory/ who found hundreds of such insecure usages. Processes with CAP_IPC_OWNER are still permitted to access these IPC objects. If the sysctl option is enabled, a sysctl option with name "harden_ipc" is created.
GRKERNSEC_TPE
相关 sysctl 变量
- kernel.grsecurity.tpe
- kernel.grsecurity.tpe_gid
If you say Y here, you will be able to choose a gid to add to the supplementary groups of users you want to mark as "untrusted." These users will not be able to execute any files that are not in root-owned directories writable only by root. If the sysctl option is enabled, a sysctl option with name "tpe" is created.
GRKERNSEC_TPE_ALL
相关 sysctl 变量
- kernel.grsecurity.tpe_restrict_all
If you say Y here, all non-root users will be covered under a weaker TPE restriction. This is separate from, and in addition to, the main TPE options that you have selected elsewhere. Thus, if a "trusted" GID is chosen, this restriction applies to even that GID. Under this restriction, all non-root users will only be allowed to execute files in directories they own that are not group or world-writable, or in directories owned by root and writable only by root. If the sysctl option is enabled, a sysctl option with name "tpe_restrict_all" is created.
GRKERNSEC_TPE_INVERT
相关 sysctl 变量
- kernel.grsecurity.tpe_invert
If you say Y here, the group you specify in the TPE configuration will decide what group TPE restrictions will be *disabled* for. This option is useful if you want TPE restrictions to be applied to most users on the system. If the sysctl option is enabled, a sysctl option with name "tpe_invert" is created. Unlike other sysctl options, this entry will default to on for backward-compatibility.
GRKERNSEC_TPE_UNTRUSTED_GID
Setting this GID determines what group TPE restrictions will be *enabled* for. If the sysctl option is enabled, a sysctl option with name "tpe_gid" is created.
GRKERNSEC_TPE_TRUSTED_GID
Setting this GID determines what group TPE restrictions will be *disabled* for. If the sysctl option is enabled, a sysctl option with name "tpe_gid" is created.
GRKERNSEC_RANDNET
If you say Y here, the entropy pools used for many features of Linux and grsecurity will be doubled in size. Since several grsecurity features use additional randomness, it is recommended that you say Y here. Saying Y here has a similar effect as modifying /proc/sys/kernel/random/poolsize.
GRKERNSEC_BLACKHOLE
相关 sysctl 变量
- kernel.grsecurity.ip_blackhole
- kernel.grsecurity.lastack_retries
If you say Y here, neither TCP resets nor ICMP destination-unreachable packets will be sent in response to packets sent to ports for which no associated listening process exists. This feature supports both IPV4 and IPV6 and exempts the loopback interface from blackholing. Enabling this feature makes a host more resilient to DoS attacks and reduces network visibility against scanners. The blackhole feature as-implemented is equivalent to the FreeBSD blackhole feature, as it prevents RST responses to all packets, not just SYNs. Under most application behavior this causes no problems, but applications (like haproxy) may not close certain connections in a way that cleanly terminates them on the remote end, leaving the remote host in LAST_ACK state. Because of this side-effect and to prevent intentional LAST_ACK DoSes, this feature also adds automatic mitigation against such attacks. The mitigation drastically reduces the amount of time a socket can spend in LAST_ACK state. If you're using haproxy and not all servers it connects to have this option enabled, consider disabling this feature on the haproxy host. If the sysctl option is enabled, two sysctl options with names "ip_blackhole" and "lastack_retries" will be created. While "ip_blackhole" takes the standard zero/non-zero on/off toggle, "lastack_retries" uses the same kinds of values as "tcp_retries1" and "tcp_retries2". The default value of 4 prevents a socket from lasting more than 45 seconds in LAST_ACK state.
GRKERNSEC_NO_SIMULT_CONNECT
If you say Y here, a feature by Willy Tarreau will be enabled that removes a weakness in Linux's strict implementation of TCP that allows two clients to connect to each other without either entering a listening state. The weakness allows an attacker to easily prevent a client from connecting to a known server provided the source port for the connection is guessed correctly. As the weakness could be used to prevent an antivirus or IPS from fetching updates, or prevent an SSL gateway from fetching a CRL, it should be eliminated by enabling this option. Though Linux is one of few operating systems supporting simultaneous connect, it has no legitimate use in practice and is rarely supported by firewalls.
GRKERNSEC_SOCKET
If you say Y here, you will be able to choose from several options. If you assign a GID on your system and add it to the supplementary groups of users you want to restrict socket access to, this patch will perform up to three things, based on the option(s) you choose.
GRKERNSEC_SOCKET_ALL
相关 sysctl 变量
- kernel.grsecurity.socket_all
- kernel.grsecurity.socket_all_gid
If you say Y here, you will be able to choose a GID of whose users will be unable to connect to other hosts from your machine or run server applications from your machine. If the sysctl option is enabled, a sysctl option with name "socket_all" is created.
GRKERNSEC_SOCKET_ALL_GID
Here you can choose the GID to disable socket access for. Remember to add the users you want socket access disabled for to the GID specified here. If the sysctl option is enabled, a sysctl option with name "socket_all_gid" is created.
GRKERNSEC_SOCKET_CLIENT
相关 sysctl 变量
- kernel.grsecurity.socket_client
- kernel.grsecurity.socket_client_gid
If you say Y here, you will be able to choose a GID of whose users will be unable to connect to other hosts from your machine, but will be able to run servers. If this option is enabled, all users in the group you specify will have to use passive mode when initiating ftp transfers from the shell on your machine. If the sysctl option is enabled, a sysctl option with name "socket_client" is created.
GRKERNSEC_SOCKET_CLIENT_GID
Here you can choose the GID to disable client socket access for. Remember to add the users you want client socket access disabled for to the GID specified here. If the sysctl option is enabled, a sysctl option with name "socket_client_gid" is created.
GRKERNSEC_SOCKET_SERVER
相关 sysctl 变量
- kernel.grsecurity.socket_server
- kernel.grsecurity.socket_server_gid
If you say Y here, you will be able to choose a GID of whose users will be unable to run server applications from your machine. If the sysctl option is enabled, a sysctl option with name "socket_server" is created.
GRKERNSEC_SOCKET_SERVER_GID
Here you can choose the GID to disable server socket access for. Remember to add the users you want server socket access disabled for to the GID specified here. If the sysctl option is enabled, a sysctl option with name "socket_server_gid" is created.
GRKERNSEC_DENYUSB
相关 sysctl 变量
- kernel.grsecurity.deny_new_usb
If you say Y here, a new sysctl option with name "deny_new_usb" will be created. Setting its value to 1 will prevent any new USB devices from being recognized by the OS. Any attempted USB device insertion will be logged. This option is intended to be used against custom USB devices designed to exploit vulnerabilities in various USB device drivers. For greatest effectiveness, this sysctl should be set after any relevant init scripts. This option is safe to enable in distros as each user can choose whether or not to toggle the sysctl.
GRKERNSEC_DENYUSB_FORCE
If you say Y here, a variant of GRKERNSEC_DENYUSB will be enabled that doesn't involve a sysctl entry. This option should only be enabled if you're sure you want to deny all new USB connections at runtime and don't want to modify init scripts. This should not be enabled by distros. It forces the core USB code to be built into the kernel image so that all devices connected at boot time can be recognized and new USB device connections can be prevented prior to init running.
GRKERNSEC_SYSCTL
If you say Y here, you will be able to change the options that grsecurity runs with at bootup, without having to recompile your kernel. You can echo values to files in /proc/sys/kernel/grsecurity to enable (1) or disable (0) various features. All the sysctl entries are mutable until the "grsec_lock" entry is set to a non-zero value. All features enabled in the kernel configuration are disabled at boot if you do not say Y to the "Turn on features by default" option. All options should be set at startup, and the grsec_lock entry should be set to a non-zero value after all the options are set. *THIS IS EXTREMELY IMPORTANT*
GRKERNSEC_SYSCTL_DISTRO
If you say Y here, additional sysctl options will be created for features that affect processes running as root. Therefore, it is critical when using this option that the grsec_lock entry be enabled after boot. Only distros with prebuilt kernel packages with this option enabled that can ensure grsec_lock is enabled after boot should use this option. *Failure to set grsec_lock after boot makes all grsec features this option covers useless* Currently this option creates the following sysctl entries: "Disable Privileged I/O": "disable_priv_io"
GRKERNSEC_SYSCTL_ON
If you say Y here, instead of having all features enabled in the kernel configuration disabled at boot time, the features will be enabled at boot time. It is recommended you say Y here unless there is some reason you would want all sysctl-tunable features to be disabled by default. As mentioned elsewhere, it is important to enable the grsec_lock entry once you have finished modifying the sysctl entries.
GRKERNSEC_FLOODTIME
This option allows you to enforce the number of seconds between grsecurity log messages. The default should be suitable for most people, however, if you choose to change it, choose a value small enough to allow informative logs to be produced, but large enough to prevent flooding. Setting both this value and GRKERNSEC_FLOODBURST to 0 will disable any rate limiting on grsecurity log messages.
GRKERNSEC_FLOODBURST
This option allows you to choose the maximum number of messages allowed within the flood time interval you chose in a separate option. The default should be suitable for most people, however if you find that many of your logs are being interpreted as flooding, you may want to raise this value. Setting both this value and GRKERNSEC_FLOODTIME to 0 will disable any rate limiting on grsecurity log messages.