Updated: 2022/Sep/29

Please read Privacy Policy. It's for your privacy.

SECURITY(7)            Miscellaneous Information Manual            SECURITY(7)

     security - NetBSD security features

     NetBSD supports a variety of security features.  Below is a brief
     description of them with some quick usage examples that will help you get


           -   Veriexec (file integrity)
           -   Exploit mitigation
           -   Per-user /tmp directory
           -   Information filtering
           -   Administrative security

     See also entropy(7).

     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 implements Address Space Layout Randomization (ASLR), meant to
     complement non-executable mappings.  Its purpose is to harden prediction
     of the address space layout, namely location of library and application
     functions that can be used by an attacker to circumvent non-executable
     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
     segfault.  To detect cases where an attacker might try and brute-force
     the return address of respawning services, PaX Segvguard can be used (see

     For non-PIE (Position Independent Executable) executables, the NetBSD PaX
     ASLR implementation introduces randomization to the following memory

           1.   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 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 MPROTECT affects the following three uses:

              Processes that utilize code generation (such as the JVM) might
               need to have MPROTECT disabled.

              Miscompiled programs that have text relocations, will now core
               dump instead of having their relocations corrected.  You will
               need to fix those programs (recompile them properly).

              Debugger breakpoints: gdb(1) needs to be able to write to the
               text segment in order to insert and delete breakpoints.  This
               will not work unless MPROTECT is disabled on the executable.

   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

           # 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:


     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.

     The so-called FORTIFY_SOURCE is a relatively simple technique to detect a
     subset of buffer overflows before these can do damage.  It is integrated
     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):


   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 all 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 following variable at

           # 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


     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

     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

     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:


     ssp(3), options(4), entropy(7), paxctl(8), sysctl(8), veriexec(8),

     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.

     Many of the security features were pioneered by Elad Efrat

NetBSD 10.99                     May 21, 2016                     NetBSD 10.99