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 an in-kernel, real-time, file-system independent, file integrity subsystem. It can be used for a variety of purposes, including defense against trojaned binaries, indirect attacks via third-party remote file-systems, and configuration file corruption. Veriexec can operate in four modes, also referred to as strict levels:

Learning mode (strict level 0)
    The only level at which the fingerprint tables can be modified, this level is used to help fine-tune the signature database. No enforcement is made, and verbose information is provided (fingerprint matches and mismatches, file removals, incorrect access, etc.).

IDS mode (strict level 1)
    IDS (intrusion detection system) mode provides an adequate level of integrity for the files it monitors. Implications:

    -   Monitored files cannot be removed
    -   If raw disk access is granted to a disk with monitored files on it, all monitored files' fingerprints will be invalidated
    -   Access to files with mismatched fingerprints is denied
    -   Write access to monitored files is allowed
    -   Access type is not enforced

IPS mode (strict level 2)
    IPS (intrusion prevention system) mode provides a high level of integrity for the files it monitors. Implications:

    -   All implications of IDS mode
    -   Write access to monitored files is denied
    -   Access type is enforced
    -   Raw disk access to disk devices with monitored files on them is denied
    -   Execution of non-monitored files is denied
    -   Write access to kernel memory via /dev/mem and /dev/kmem is denied

Lockdown mode (strict level 3)
    Lockdown mode provides high assurance integrity for the entire system. Implications:

    -   All implications of IPS mode
    -   Access to non-monitored files is denied
    -   Write access to files is allowed only if the file was opened before the strict level was raised to this mode
    -   Creation of new files is denied
    -   Raw access to system disks is denied

Veriexec requires a list of monitored files, along with their digital fingerprint and (optionally) access modes. NetBSD provides a tool, veriexecgen(8), for this purpose. Example usage:

    # veriexecgen

Veriexec requires a pseudo-device to run:

    pseudo-device veriexec 1

Additionally, one or more options for digital fingerprint algorithm support:

    options VERIFIED_EXEC_FP_SHA256
    options VERIFIED_EXEC_FP_SHA512

See your kernel's config file for an example.

On amd64, i386, prep, and sparc64 GENERIC kernels, Veriexec is enabled by default.

Veriexec also requires enabling in rc.conf(5):

    veriexec=YES
    veriexec_strict=1 # IDS mode

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 MPROTECT ((mprotect) 2 restrictions)
-   PaX SegvGuard
-   gcc(1) stack-smashing protection (SSP)

  PaX MPROTECT
PaX MPROTECT implements memory protection restrictions, meant to complement non-executable mappings. Their 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, 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, firewalls, 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 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.

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), veriexecctl(8), veriexecgen(8)

AUTHORS
Elad Efrat <elad@NetBSD.org>