security(8) - NetBSD Manual Pages

SECURITY(8)             NetBSD System Manager's Manual             SECURITY(8)


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


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 impact 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)

   PaX ASLR
     PaX ASLR implements Address Space Layout Randomization, meant to comple-
     ment non-executable mappings.  Its purpose is to harden prediction of the
     address space layout, namely location of library and application func-
     tions that can be used by an attacker to circumvent non-executable map-
     pings 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 pre-
     dict 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 memory
     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 comple-
     ment non-executable mappings.  Their purpose is to prevent situations
     where malicious code attempts to mark writable memory regions as exe-
     cutable, 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 pro-
     vides 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 mem-
     ory.

     For this reason, it is highly recommended to have PaX Segvguard enabled
     explicitly only for network services, etc.  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 (some network appliances, embedded devices, fire-
     walls, etc.):

           # 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 exam-
     ple, 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 vari-
     ables 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.


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


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


SEE ALSO

     sysctl(3), options(4), paxctl(8), sysctl(8), veriexec(8), veriexecctl(8),
     veriexecgen(8)


AUTHORS

     Elad Efrat <elad@NetBSD.org>

NetBSD 5.0                     January 26, 2009                     NetBSD 5.0