paxctl(1) [debian man page]
paxctl(1) PaX paxctl(1) NAME
paxctl - user-space utility to control PaX flags SYNTAX
paxctl <flags> <files> DESCRIPTION
paxctl is a tool that allows PaX flags to be modified on a per-binary basis. PaX is part of common security-enhancing kernel patches and secure distributions, such as GrSecurity and Hardened Gentoo, respectively. Your system needs to be running a properly patched and config- ured kernel for this program to have any effect. -P enforce paging based non-executable pages (PAGEEXEC) -p do not enforce paging based non-executable pages (NOPAGEEXEC) -E emulate trampolines (EMUTRAMP) -e do not emulate trampolines (NOEMUTRAMP) -M enforce secure memory protections (MPROTECT) -m do not enforce secure memory protections (NOMPROTECT) -R randomize memory regions (RANDMMAP) -r do not randomize memory regions (NORANDMMAP) -X randomize base address of normal (ET_EXEC) executables (RANDEXEC) -x do not randomize base address of normal (ET_EXEC) executables (NORANDEXEC) -S enforce segmentation based non-executable pages (SEGMEXEC) -s do not enforce segmentation based non-executable pages (NOSEGMEXEC) -v view flags -z reset all flags (further flags still apply) -c create the PT_PAX_FLAGS program header if it does not exist by converting the PT_GNU_STACK program header if it exists -C create the PT_PAX_FLAGS program header if it does not exist by adding a new program header, if it is possible -q suppress error messages -Q report flags in short format CAVEATS
The old PaX flag location and control method have been obsoleted, if your kernel and binaries use it you have to use chpax(1) instead (it is recommended to use PT_PAX_FLAGS along with -c or -C however). Converting PT_GNU_STACK into PT_PAX_FLAGS means that the information in the former is destroyed, in particular you must make sure that the EMUTRAMP PaX option is properly set in the newly created PT_PAX_FLAGS. The secure way is to disable EMUTRAMP first and if PaX reports stack execution attempts from nested function trampolines then enable it. Note that the new PT_PAX_FLAGS is created in the same state that binutils/ld itself would produce (equivalent to -zex). Note that if you use both PT_PAX_FLAGS and the extended attribute PaX flags on a binary then they must be exactly the same (except for RAN- DEXEC). Note that RANDEXEC is no longer supported by PaX kernels since 2.6.13, the paxctl flags are simply ignored there. Note that paxctl does not make backup copies of the files it modifies. Note that paxctl is meant to work on the native architecture's binaries only, however it should work on foreign binaries as long as they have the same endianess as the native architecture (e.g., an i386 paxctl should work on amd64 or little-endian arm but not on big-endian mips binaries). AUTHOR
Written by The PaX Team <pageexec@freemail.hu> This manpage was adapted from the chpax manpage written by Martin F. Krafft <madduck@debian.org> for the Debian GNU/Linux Distribution, but may be used by others. SEE ALSO
chpax(1), gradm(8) PaX website: http://pax.grsecurity.net GrSecurity website: http://www.grsecurity.net Hardened Gentoo website: http://www.gentoo.org/proj/en/hardened paxctl Manual 2012-02-19 paxctl(1)
Check Out this Related Man Page
SECURITY(7) BSD Miscellaneous Information Manual SECURITY(7) NAME
security -- NetBSD security features DESCRIPTION
NetBSD supports a variety of security features. Below is a brief description of them with some quick usage examples that will help you get started. Contents: - Veriexec (file integrity) - Exploit mitigation - Per-user /tmp directory - Information filtering - Administrative security Veriexec Veriexec is a file integrity subsystem. For more information about it, and a quick guide on how to use it, please see veriexec(8). In a nutshell, once enabled, Veriexec can be started as follows: # veriexecgen && veriexecctl load Exploit mitigation NetBSD incorporates some exploit mitigation features. The purpose of exploit mitigation features is to interfere with the way exploits work, in order to prevent them from succeeding. Due to that, some features may have other impacts on the system, so be sure to fully understand the implications of each feature. NetBSD provides the following exploit mitigation features: - PaX ASLR (Address Space Layout Randomization). - PaX MPROTECT (mprotect(2) restrictions) - PaX SegvGuard - gcc(1) stack-smashing protection (SSP) - bounds checked libc functions (FORTIFY_SOURCE) - Protections against NULL pointer dereferences PaX ASLR PaX ASLR implements Address Space Layout Randomization (ASLR), meant to complement non-executable mappings. Its purpose is to harden predic- tion of the address space layout, namely location of library and application functions that can be used by an attacker to circumvent non-exe- cutable mappings by using a technique called ``return to library'' to bypass the need to write new code to (potentially executable) regions of memory. When PaX ASLR is used, it is more likely the attacker will fail to predict the addresses of such functions, causing the application to seg- fault. To detect cases where an attacker might try and brute-force the return address of respawning services, PaX Segvguard can be used (see below). For non-PIE (Position Independent Executable) executables, the NetBSD PaX ASLR implementation introduces randomization to the following mem- ory regions: 1. The data segment 2. The stack For PIE executables: 1. The program itself (exec base) 2. All shared libraries 3. The data segment 4. The stack While it can be enabled globally, NetBSD provides a tool, paxctl(8), to enable PaX ASLR on a per-program basis. Example usage: # paxctl +A /usr/sbin/sshd Enabling PaX ASLR globally: # sysctl -w security.pax.aslr.global=1 PaX MPROTECT PaX MPROTECT implements memory protection restrictions, meant to complement non-executable mappings. The purpose is to prevent situations where malicious code attempts to mark writable memory regions as executable, often by trashing arguments to an mprotect(2) call. While it can be enabled globally, NetBSD provides a tool, paxctl(8), to enable PaX MPROTECT on a per-program basis. Example usage: # paxctl +M /usr/sbin/sshd Enabling PaX MPROTECT globally: # sysctl -w security.pax.mprotect.global=1 PaX Segvguard PaX Segvguard monitors the number of segmentation faults in a program on a per-user basis, in an attempt to detect on-going exploitation attempts and possibly prevent them. For instance, PaX Segvguard can help detect when an attacker tries to brute-force a function return address, when attempting to perform a return-to-lib attack. PaX Segvguard consumes kernel memory, so use it wisely. While it provides rate-limiting protections, records are tracked for all users on a per-program basis, meaning that irresponsible use may result in tracking all segmentation faults in the system, possibly consuming all kernel memory. For this reason, it is highly recommended to have PaX Segvguard enabled explicitly only for network services or other processes deemed as critical to system security. Enabling PaX Segvguard explicitly works like this: # paxctl +G /usr/sbin/sshd However, a global knob is still provided, for use in strict environments with no local users (for example, some network appliances, embedded devices, and firewalls) # sysctl -w security.pax.segvguard.global=1 Explicitly disabling PaX Segvguard is also possible: # paxctl +g /bin/ls In addition, PaX Segvguard provides several tunable options. For example, to limit a program to 5 segmentation faults from the same user in a 60 second timeframe: # sysctl -w security.pax.segvguard.max_crashes=5 # sysctl -w security.pax.segvguard.expiry_timeout=60 The number of seconds a user will be suspended from running the culprit program is also configurable. For example, 10 minutes seem like a sane setting: # sysctl -w security.pax.segvguard.suspend_timeout=600 GCC Stack Smashing Protection (SSP) As of NetBSD 4.0, gcc(1) includes SSP, a set of compiler extensions to raise the bar on exploitation attempts by detecting corruption of variables and buffer overruns, which may be used to affect program control flow. Upon detection of a buffer overrun, SSP will immediately abort execution of the program and send a log message to syslog(3). The system (userland and kernel) can be built with SSP by using the ``USE_SSP'' flag in /etc/mk.conf: USE_SSP=yes You are encouraged to use SSP for software you build, by providing one of the -fstack-protector or -fstack-protector-all flags to gcc(1). Keep in mind, however, that SSP will not work for functions that make use of alloca(3), as the latter modifies the stack size during run- time, while SSP relies on it being a compile-time static. Use of SSP is especially encouraged on platforms without per-page execute bit granularity such as i386. As of NetBSD 6.0, SSP is used by default on i386 and amd64 architectures. FORTIFY_SOURCE The so-called FORTIFY_SOURCE is a relatively simple technique to detect a subset of buffer overflows before these can do damage. It is inte- grated to gcc(1) together with some common memory and string functions in the standard C library of NetBSD. The underlying idea builds on the observation that there are cases where the compiler knows the size of a buffer. If a buffer overflow is suspected in a function that does little or no bounds checking, either a compile time warning can be issued or a safer substitute function can be used at runtime. Refer to ssp(3) for additional details. The FORTIFY_SOURCE is enabled by default in some parts of the NetBSD source tree. It is also possible to explicitly enable it by defining the following in mk.conf(5): USE_FORT=yes Protections against NULL pointer dereferences A certain class of attacks rely on kernel bugs that dereference NULL pointers. If user processes are allowed to map the virtual address 0 with mmap(2) or by other means, there is a risk that code or data can be injected into the kernel address space. In NetBSD it is possible to restrict whether user processes are allowed to make mappings at the zero address. By default, address 0 mappings are restricted on the i386 and amd64 architectures. It is however known that some third-party programs may not function properly with the restriction. Such mappings can be allowed either by using the USER_VA0_DISABLE_DEFAULT kernel configuration option or by changing the fol- lowing variable at runtime: # sysctl -w vm.user_va0_disable=0 Note that if securelevel (see secmodel_securelevel(9)) is greater than zero, it is not possible to change the sysctl(8) variable. Per-user temporary storage It is possible to configure per-user temporary storage to avoid potential security issues (race conditions, etc.) in programs that do not make secure usage of /tmp. To enable per-user temporary storage, add the following line to rc.conf(5): per_user_tmp=YES If /tmp is a mount point, you will also need to update its fstab(5) entry to use ``/private/tmp'' (or whatever directory you want, if you override the default using the ``per_user_tmp_dir'' rc.conf(5) keyword) instead of ``/tmp''. Following that, run: # /etc/rc.d/perusertmp start The per-user temporary storage is implemented by using ``magic symlinks''. These are further described in symlink(7). Information filtering NetBSD provides administrators the ability to restrict information passed from the kernel to userland so that users can only view information they ``own''. The hooks that manage this restriction are located in various parts of the system and affect programs such as ps(1), fstat(1), and netstat(1). Information filtering is enabled as follows: # sysctl -w security.curtain=1 Administrative security Also certain administrative tasks are related to security. For instance, the daily maintenance script includes some basic consistency checks; see security.conf(5) for more details. In particular, it is possible to configure NetBSD to automatically audit all third-party packages installed via pkgsrc(7). To audit for any known vulnerabilities on daily basis, set the following in /etc/daily.conf: fetch_pkg_vulnerabilities=YES SEE ALSO
ssp(3), options(4), paxctl(8), sysctl(8), veriexec(8), kauth(9) Joseph Kong, Designing BSD Rootkits: An Introduction to Kernel Hacking, No Starch Press, 2007. Enrico Perla and Massimiliano Oldani, A Guide to Kernel Exploitation: Attacking the Core, Elsevier, 2010. Erik Buchanan, Ryan Roemer, Hovav Shacham, and Stefan Savage, When Good Instructions Go Bad: Generalizing Return-Oriented Programming to RISC, ACM Press, http://cseweb.ucsd.edu/~hovav/dist/sparc.pdf, 27-38, October 27-31, 2008, CCS '08: Proceedings of the 15th ACM Conference on Computer and Communications Security. Sebastian Krahmer, x86-64 Buffer Overflow Exploits and the Borrowed Code Chunks Exploitation Technique, http://www.suse.de/~krahmer/no- nx.pdf, September 28, 2005. AUTHORS
Many of the security features were pioneered by Elad Efrat <elad@NetBSD.org>. BSD
March 30, 2011 BSD