SOURCES: grsecurity-2.1.8-2.4.32-200601211647.patch (NEW) - raw fr...
zbyniu
zbyniu at pld-linux.org
Mon Feb 6 21:13:26 CET 2006
Author: zbyniu Date: Mon Feb 6 20:13:25 2006 GMT
Module: SOURCES Tag: HEAD
---- Log message:
- raw from http://www.grsecurity.net/grsecurity-2.1.8-2.4.32-200601211647.patch.gz (gunzipped)
---- Files affected:
SOURCES:
grsecurity-2.1.8-2.4.32-200601211647.patch (NONE -> 1.1) (NEW)
---- Diffs:
================================================================
Index: SOURCES/grsecurity-2.1.8-2.4.32-200601211647.patch
diff -u /dev/null SOURCES/grsecurity-2.1.8-2.4.32-200601211647.patch:1.1
--- /dev/null Mon Feb 6 21:13:25 2006
+++ SOURCES/grsecurity-2.1.8-2.4.32-200601211647.patch Mon Feb 6 21:13:20 2006
@@ -0,0 +1,22701 @@
+diff -urNp linux-2.4.32/Documentation/Configure.help linux-2.4.32/Documentation/Configure.help
+--- linux-2.4.32/Documentation/Configure.help 2005-11-16 14:12:54.000000000 -0500
++++ linux-2.4.32/Documentation/Configure.help 2006-01-21 16:36:58.408414832 -0500
+@@ -2899,6 +2899,20 @@ CONFIG_IP_NF_MATCH_PKTTYPE
+ If you want to compile it as a module, say M here and read
+ Documentation/modules.txt. If unsure, say `N'.
+
++stealth networking support
++CONFIG_IP_NF_MATCH_STEALTH
++ Enabling this option will drop all syn packets coming to unserved tcp
++ ports as well as all packets coming to unserved udp ports. If you
++ are using your system to route any type of packets (ie. via NAT)
++ you should put this module at the end of your ruleset, since it will
++ drop packets that aren't going to ports that are listening on your
++ machine itself, it doesn't take into account that the packet might be
++ destined for someone on your internal network if you're using NAT for
++ instance.
++
++ If you want to compile it as a module, say M here and read
++ Documentation/modules.txt. If unsure, say `N'.
++
+ MAC address match support
+ CONFIG_IP_NF_MATCH_MAC
+ MAC matching allows you to match packets based on the source
+@@ -23430,6 +23444,941 @@ CONFIG_CF_AREA5
+
+ "Area6" will work for most boards. For ADX, select "Area5".
+
++Grsecurity
++CONFIG_GRKERNSEC
++ If you say Y here, you will be able to configure many features that
++ will enhance the security of your system. It is highly recommended
++ that you say Y here and read through the help for each option so
++ you fully understand the features and can evaluate their usefulness
++ for your machine.
++
++Additional security levels
++CONFIG_GRKERNSEC_LOW
++
++ Low additional security
++ -----------------------------------------------------------------------
++ If you choose this option, several of the grsecurity options will
++ be enabled that will give you greater protection against a number
++ of attacks, while assuring that none of your software will have any
++ conflicts with the additional security measures. If you run a lot of
++ unusual software, or you are having problems with the higher security
++ levels, you should say Y here. With this option, the following features
++ are enabled:
++
++ linking restrictions
++ fifo restrictions
++ random pids
++ enforcing nproc on execve()
++ restricted dmesg
++ enforced chdir("/") on chroot
++ runtime module disabling
++
++ Medium additional security
++ -----------------------------------------------------------------------
++ If you say Y here, several features in addition to those included in the
++ low additional security level will be enabled. These features provide
++ even more security to your system, though in rare cases they may
++ be incompatible with very old or poorly written software. If you
++ enable this option, make sure that your auth service (identd) is
++ running as gid 10 (usually group wheel). With this option the following
++ features (in addition to those provided in the low additional security
++ level) will be enabled:
++
++ random tcp source ports
++ failed fork logging
++ time change logging
++ signal logging
++ deny mounts in chroot
++ deny double chrooting
++ deny sysctl writes in chroot
++ deny mknod in chroot
++ deny access to abstract AF_UNIX sockets out of chroot
++ deny pivot_root in chroot
++ denied writes of /dev/kmem, /dev/mem, and /dev/port
++ /proc restrictions with special gid set to 10 (usually wheel)
++ address space layout randomization
++ removal of addresses from /proc/<pid>/[maps|stat]
++
++ High additional security
++ ----------------------------------------------------------------------
++ If you say Y here, many of the features of grsecurity will be enabled,
++ that will protect you against many kinds of attacks against
++ your system. The heightened security comes at a cost of an
++ increased chance of incompatibilities with rare software on your
++ machine. Since this security level enables PaX, you should view
++ <http://pax.grsecurity.net> and read about the PaX project. While
++ you are there, download chpax and run it on binaries that cause
++ problems with PaX. Also remember that since the /proc restrictions are
++ enabled, you must run your identd as group wheel (gid 10).
++ This security level enables the following features in addition to those
++ listed in the low and medium security levels:
++
++ additional /proc restrictions
++ chmod restrictions in chroot
++ no signals, ptrace, or viewing processes outside of chroot
++ capability restrictions in chroot
++ deny fchdir out of chroot
++ priority restrictions in chroot
++ segmentation-based implementation of PaX
++ mprotect restrictions
++ kernel stack randomization
++ mount/unmount/remount logging
++ kernel symbol hiding
++ destroy unused shared memory
++
++Customized additional security
++CONFIG_GRKERNSEC_CUSTOM
++ If you say Y here, you will be able to configure every grsecurity
++ option, which allows you to enable many more features that aren't
++ covered in the basic security levels. These additional features include
++ TPE, socket restrictions, and the sysctl system for grsecurity. It is
++ advised that you read through the help for each option to determine its
++ usefulness in your situation.
++
++Support soft mode
++CONFIG_GRKERNSEC_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 support as it
++ is the only way to mark executables for soft mode use.
++
++ Soft mode can be activated by using the "pax_softmode=1" kernel command
++ line option on boot. Furthermore you can control various PaX features
++ at runtime via the entries in /proc/sys/kernel/pax.
++
++Use legacy ELF header marking
++CONFIG_GRKERNSEC_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 support.
++
++ If you have applications not marked by the PT_PAX_FLAGS ELF
++ program header then you MUST enable this option otherwise they
++ will not get any protection.
++
++ Note that if you enable PT_PAX_FLAGS marking support as well,
++ the PT_PAX_FLAG marks will override the legacy EI_PAX marks.
++
++Use ELF program header marking
++CONFIG_GRKERNSEC_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).
++
++ If you have applications not marked by the PT_PAX_FLAGS ELF
++ program header then you MUST enable the EI_PAX marking support
++ otherwise they will not get any protection.
++
++ 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.
++
++MAC system integration
++CONFIG_GRKERNSEC_PAX_NO_ACL_FLAGS
++ Mandatory Access Control systems have the option of controlling
++ PaX flags on a per executable basis, choose the method supported
++ by your particular system.
++
++ - "none": if your MAC system does not interact with PaX,
++ - "direct": if your MAC system defines pax_set_flags() itself,
++ - "hook": if your MAC system uses the pax_set_flags_func callback.
++
++ NOTE: this option is for developers/integrators only.
++
++Enforce non-executable pages
++CONFIG_GRKERNSEC_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.
++
++Paging based non-executable pages
++CONFIG_GRKERNSEC_PAX_PAGEEXEC
++ This implementation is based on the paging feature of the CPU.
++ On i386 it has a variable performance impact on applications
++ depending on their memory usage pattern. You should carefully
++ test your applications before using this feature in production.
++ On alpha, parisc, sparc and sparc64 there is no performance
++ impact. On ppc there is a slight performance impact.
++
++Segmentation based non-executable pages
++CONFIG_GRKERNSEC_PAX_SEGMEXEC
++ This implementation is based on the segmentation feature of the
++ CPU and has little performance impact, however applications will
++ be limited to a 1.5 GB address space instead of the normal 3 GB.
++
++Emulate trampolines
++CONFIG_GRKERNSEC_PAX_EMUTRAMP
++ There are some programs and libraries that for one reason or
++ another attempt to execute special small code snippets from
++ non-executable memory pages. Most notable examples are the
++ signal handler return code generated by the kernel itself and
++ the GCC trampolines.
++
++ If you enabled CONFIG_GRKERNSEC_PAX_PAGEEXEC or
++ CONFIG_GRKERNSEC_PAX_SEGMEXEC then such programs will no longer
++ work under your kernel.
++
++ As a remedy you can say Y here and use the 'chpax' or 'paxctl'
++ utilities to enable trampoline emulation for the affected programs
++ yet still have the protection provided by the non-executable pages.
++
++ On parisc and ppc you MUST enable this option and EMUSIGRT as
++ well, otherwise your system will not even boot.
++
++ Alternatively you can say N here and use the 'chpax' or 'paxctl'
++ utilities to disable CONFIG_GRKERNSEC_PAX_PAGEEXEC and
++ CONFIG_GRKERNSEC_PAX_SEGMEXEC for the affected files.
++
++ NOTE: enabling this feature *may* open up a loophole in the
++ protection provided by non-executable pages that an attacker
++ could abuse. Therefore the best solution is to not have any
++ files on your system that would require this option. This can
++ be achieved by not using libc5 (which relies on the kernel
++ signal handler return code) and not using or rewriting programs
++ that make use of the nested function implementation of GCC.
++ Skilled users can just fix GCC itself so that it implements
++ nested function calls in a way that does not interfere with PaX.
++
++Automatically emulate sigreturn trampolines
++CONFIG_GRKERNSEC_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 and ppc you MUST enable this option, otherwise your
++ system will not even boot.
++
++ NOTE: this feature cannot be disabled on a per executable basis
++ and since it *does* open up a loophole in the protection provided
++ by non-executable pages, the best solution is to not have any
++ files on your system that would require this option.
++
++Restrict mprotect()
++CONFIG_GRKERNSEC_PAX_MPROTECT
++ Enabling this option will prevent programs from
++ - changing the executable status of memory pages that were
++ not originally created as executable,
++ - making read-only executable pages writable again,
++ - creating executable pages from anonymous memory.
++
++ You should say Y here to complete the protection provided by
++ the enforcement of non-executable pages.
++
++ NOTE: you can use the 'chpax' utility to control this
++ feature on a per file basis. chpax is available at
++ <http://pax.grsecurity.net>
++
++Disallow ELF text relocations
++CONFIG_GRKERNSEC_PAX_NOELFRELOCS
++ Non-executable pages and mprotect() restrictions are effective
++ in preventing the introduction of new executable code into an
++ attacked task's address space. There remain only two venues
++ for this kind of attack: if the attacker can execute already
++ existing code in the attacked task then he can either have it
++ create and mmap() a file containing his code or have it mmap()
++ an already existing ELF library that does not have position
++ independent code in it and use mprotect() on it to make it
++ writable and copy his code there. While protecting against
++ the former approach is beyond PaX, the latter can be prevented
++ by having only PIC ELF libraries on one's system (which do not
++ need to relocate their code). If you are sure this is your case,
++ then enable this option otherwise be careful as you may not even
++ be able to boot or log on your system (for example, some PAM
++ modules are erroneously compiled as non-PIC by default).
++
++ NOTE: if you are using dynamic ELF executables (as suggested
++ when using ASLR) then you must have made sure that you linked
++ your files using the PIC version of crt1 (the et_dyn.zip package
++ referenced there has already been updated to support this).
++
++Enforce non-executable kernel pages
++CONFIG_GRKERNSEC_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.
++
++Address Space Layout Randomization
++CONFIG_GRKERNSEC_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 grsecurity's
++ built-in crash detection features or develop one yourself.
++
++ By saying Y here you can choose to randomize the following areas:
++ - top of the task's kernel stack
++ - top of the task's userland stack
++ - base address for mmap() requests that do not specify one
++ (this includes all libraries)
++ - base address of the main executable
++
++ It is strongly recommended to say Y here as address space layout
++ randomization has negligible impact on performance yet it provides
++ a very effective protection.
++
++ NOTE: you can use the 'chpax' or 'paxctl' utilities to control most
++ of these features on a per file basis.
++
++Randomize kernel stack base
++CONFIG_GRKERNSEC_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.
++
++Randomize user stack base
++CONFIG_GRKERNSEC_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.
++
++Randomize ET_EXEC base
++CONFIG_GRKERNSEC_PAX_RANDEXEC
++ By saying Y here the kernel will randomize the base address of normal
++ ET_EXEC ELF executables as well. This is accomplished by mapping the
++ executable in memory in a special way which also allows for detecting
++ attackers who attempt to execute its code for their purposes. Since
++ this special mapping causes performance degradation and the attack
++ detection may create false alarms as well, you should carefully test
++ your executables when this feature is enabled.
++
++ This solution is intended only as a temporary one until you relink
++ your programs as a dynamic ELF file.
++
++ NOTE: you can use the 'chpax' or 'paxctl' utilities to control
++ this feature on a per file basis.
++
++Allow ELF ET_EXEC text relocations
++CONFIG_GRKERNSEC_PAX_ETEXECRELOCS
++ On some architectures like the alpha there are incorrectly
++ created applications that require text relocations and would
++ not work without enabling this option. If you are an alpha
++ user, you should enable this option and disable it once you
++ have made sure that none of your applications need it.
++
++Automatically emulate ELF PLT
++CONFIG_GRKERNSEC_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, ppc,
++ sparc and sparc64, otherwise your system would not even boot.
++
++ NOTE: this feature *does* open up a loophole in the protection
++ provided by the non-executable pages, therefore the proper
++ solution is to modify the toolchain to produce a PLT that does
++ not need to be writable.
++
++Randomize mmap() base
++CONFIG_GRKERNSEC_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.zip> and practical samples at
++ <http://www.grsecurity.net/grsec-gcc-specs.tar.gz> .
++
++ NOTE: you can use the 'chpax' or 'paxctl' utilities to control this
++ feature on a per file basis.
++
++Deny writing to /dev/kmem, /dev/mem, and /dev/port
++CONFIG_GRKERNSEC_KMEM
++ If you say Y here, /dev/kmem and /dev/mem won't be allowed to
++ be written to via mmap or otherwise to modify the running kernel.
++ /dev/port will also not be allowed to be opened. If you have module
++ support disabled, enabling this will close up four ways that are
++ currently used to insert malicious code into the running kernel.
++ Even with all these features enabled, we still highly recommend that
++ you use the RBAC system, as it is still possible for an attacker to
++ modify the running kernel through privileged I/O granted by ioperm/iopl.
++ If you are not using XFree86, you may be able to stop this additional
++ case by enabling the 'Disable privileged I/O' option. Though nothing
++ legitimately writes to /dev/kmem, XFree86 does need to write to /dev/mem,
++ but only to video memory, which is the only writing we allow in this
++ case. If /dev/kmem or /dev/mem are mmaped without PROT_WRITE, they will
++ not be allowed to mprotect it with PROT_WRITE later.
++ It is highly recommended that you say Y here if you meet all the
++ conditions above.
++
++Disable privileged I/O
++CONFIG_GRKERNSEC_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 CONFIG_RTC is
++ enabled if this option is enabled, to ensure that hwclock operates
++ correctly. XFree86 still will not operate correctly with this option
++ enabled, so DO NOT CHOOSE Y IF YOU USE XFree86. If you use XFree86
++ and you still want to protect your kernel against modification,
++ use the RBAC system.
++
++Runtime module disabling
++CONFIG_GRKERNSEC_MODSTOP
++ If you say Y here, you will be able to disable the ability to (un)load
++ modules at runtime. This feature is useful if you need the ability
++ to load kernel modules at boot time, but do not want to allow an
++ attacker to load a rootkit kernel module into the system, or to remove
++ a loaded kernel module important to system functioning. You should
++ enable the /dev/mem protection feature as well, since rootkits can be
++ inserted into the kernel via other methods than kernel modules. Since
++ an untrusted module could still be loaded by modifying init scripts and
++ rebooting the system, it is also recommended that you enable the RBAC
++ system. If you enable this option, a sysctl option with name
++ "disable_modules" will be created. Setting this option to "1" disables
++ module loading. After this option is set, no further writes to it are
++ allowed until the system is rebooted.
++
++Hide kernel symbols
++CONFIG_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. This option is only effective
++ provided the following conditions are met:
++ 1) The kernel using grsecurity is not precompiled by some distribution
++ 2) You are using the RBAC system and hiding other files such as your
++ kernel image and System.map
++ 3) You have the additional /proc restrictions enabled, which removes
++ /proc/kcore
++ If the above conditions are met, this option will aid to provide a
++ useful protection against local and remote kernel exploitation of
++ overflows and arbitrary read/write vulnerabilities.
++
++Deter exploit bruteforcing
++CONFIG_GRKERNSEC_BRUTE
++ If you say Y here, attempts to bruteforce exploits against forking
++ daemons such as apache or sshd will be deterred. When a child of a
++ forking daemon is killed by PaX or crashes due to an illegal
++ instruction, 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. It is recommended that you also
++ enable signal logging in the auditing section so that logs are
++ generated when a process performs an illegal instruction.
++
++/proc/<pid>/ipaddr support
++CONFIG_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.
++
++Proc Restrictions
++CONFIG_GRKERNSEC_PROC
++ If you say Y here, the permissions of the /proc filesystem
++ will be altered to enhance system security and privacy. You MUST
++ choose either a user only restriction or a user and group restriction.
++ Depending upon the option you choose, you can either restrict users to
++ see only the processes they themselves run, or choose a group that can
++ view all processes and files normally restricted to root if you choose
++ the "restrict to user only" option. NOTE: If you're running identd as
++ a non-root user, you will have to run it as the group you specify here.
++
++Restrict /proc to user only
++CONFIG_GRKERNSEC_PROC_USER
++ If you say Y here, non-root users will only be able to view their own
++ processes, and restricts them from viewing network-related information,
++ and viewing kernel symbol and module information.
++
++Restrict /proc to user and group
++CONFIG_GRKERNSEC_PROC_USERGROUP
++ If you say Y here, you will be able to select a group that will be
++ able to view all processes, network-related information, and
++ kernel and symbol information. This option is useful if you want
++ to run identd as a non-root user.
++
++Remove addresses from /proc/pid/[maps|stat]
++CONFIG_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.
++ If you use PaX it is greatly recommended that you say Y here as it
++ closes up a hole that makes the full ASLR useless for suid
++ binaries.
++
++Additional proc restrictions
++CONFIG_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.
++
++Dmesg(8) Restriction
++CONFIG_GRKERNSEC_DMESG
++ If you say Y here, non-root users will not be able to use dmesg(8)
++ to view up to the last 4kb of messages in the kernel's log buffer.
++ If the sysctl option is enabled, a sysctl option with name "dmesg" is
++ created.
++
++Destroy unused shared memory
++CONFIG_GRKERNSEC_SHM
++ If you say Y here, shared memory will be destroyed when no one is
++ attached to it. Otherwise, resources involved with the shared
++ memory can be used up and not be associated with any process (as the
++ shared memory still exists, and the creating process has exited). If
++ the sysctl option is enabled, a sysctl option with name
++ "destroy_unused_shm" is created.
++
++Linking restrictions
++CONFIG_GRKERNSEC_LINK
++ If you say Y here, /tmp race exploits will be prevented, since users
++ will no longer be able to follow symlinks owned by other users in
++ world-writable +t directories (i.e. /tmp), unless the owner of the
++ symlink is the owner of the directory. users will also not be
++ able to hardlink to files they do not own. If the sysctl option is
++ enabled, a sysctl option with name "linking_restrictions" is created.
++
++FIFO restrictions
++CONFIG_GRKERNSEC_FIFO
++ If you say Y here, users will not be able to write to FIFOs they don't
++ own in world-writable +t directories (i.e. /tmp), unless the owner of
++ the FIFO is the same owner of the directory it's held in. If the sysctl
++ option is enabled, a sysctl option with name "fifo_restrictions" is
++ created.
++
++Enforce RLIMIT_NPROC on execs
++CONFIG_GRKERNSEC_EXECVE
++ If you say Y here, users with a resource limit on processes will
++ have the value checked during execve() calls. The current system
++ only checks the system limit during fork() calls. If the sysctl option
++ is enabled, a sysctl option with name "execve_limiting" is created.
++
++Single group for auditing
++CONFIG_GRKERNSEC_AUDIT_GROUP
++ If you say Y here, the exec, chdir, (un)mount, and ipc logging features
++ will only operate on a group you specify. This option is recommended
++ if you only want to watch certain users instead of having a large
++ amount of logs from the entire system. If the sysctl option is enabled,
++ a sysctl option with name "audit_group" is created.
++
<<Diff was trimmed, longer than 597 lines>>
More information about the pld-cvs-commit
mailing list