SECMODEL_SECURELEVEL(9) Kernel Developer's Manual SECMODEL_SECURELEVEL(9)
NAME
secmodel_securelevelsecurelevel security model
DESCRIPTION
The securelevel mechanism is intended to allow protecting the persistence of code and data on the system, or a subset thereof, from modification, even by the super-user, by providing convenient means of “locking down” a system to a degree suited to its environment.
 
The super-user can raise the securelevel using sysctl(8), but only init(8) can lower it.
 
secmodel_securelevel provides four levels of securelevel, defined as follows:
-1 Permanently insecure mode
Don't raise the securelevel on boot
 0 Insecure mode
The init process (PID 1) may not be traced or accessed by ptrace(2) or procfs.
Immutable and append-only file flags may be changed
All devices may be read or written subject to their permissions
GPIO pins can be set and device drivers can be attached to them
 1 Secure mode
All effects of securelevel 0
/dev/mem and /dev/kmem may not be written to
Raw disk devices of mounted file systems are read-only
Immutable and append-only file flags may not be removed
Kernel modules may not be loaded or unloaded
The net.inet.ip.sourceroute sysctl(8) variable may not be changed
Adding or removing sysctl(9) nodes is denied
The RTC offset may not be changed
Set-id coredump settings may not be altered
Attaching the IP-based kernel debugger, ipkdb(4), is not allowed
Device “pass-thru” requests that may be used to perform raw disk and/or memory access are denied
iopl and ioperm calls are denied
Access to unmanaged memory is denied
Only GPIO pins that have been set at securelevel 0 can be accessed
 2 Highly secure mode
All effects of securelevel 1
Raw disk devices are always read-only whether mounted or not
New disks may not be mounted, and existing mounts may only be downgraded from read-write to read-only
The system clock may not be set backwards or close to overflow
Per-process coredump name may not be changed
Packet filtering and NAT rules may not be altered
 
Highly secure mode may seem Draconian, but is intended as a last line of defence should the superuser account be compromised. Its effects preclude circumvention of file flags by direct modification of a raw disk device, or erasure of a file system by means of newfs(8). Further, it can limit the potential damage of a compromised “firewall” by prohibiting the modification of packet filter rules. Preventing the system clock from being set backwards aids in post-mortem analysis and helps ensure the integrity of logs. Precision timekeeping is not affected because the clock may still be slowed.
 
Normally, the system runs in securelevel 0 while single-user and in securelevel 1 while multi-user. If a higher securelevel is desired while running multi-user, it can be set using the securelevel keyword in the startup script /etc/rc.conf, see rc.conf(5) for details. Lower securelevels require the kernel to be compiled with options INSECURE, causing it to always default to securelevel -1.
 
In order for this protection to be effective, the administrator must ensure that no program that is run while the security level is 0 or lower, nor any data or configuration file used by any such program, can be modified while the security level is greater than 0. This may be achieved through the careful use of the “immutable” file flag to define and protect a Trusted Computing Base (TCB) consisting of all such programs and data, or by ensuring that all such programs and data are on filesystems that are mounted read-only and running at security level 2 or higher. Particular care must be taken to ensure, if relying upon security level 1 and the use of file flags, that the integrity of the TCB cannot be compromised through the use of modifications to the disklabel or access to overlapping disk partitions, including the raw partition.
 
Do not overlook the fact that shell scripts (or anything else fed to an interpreter, through any mechanism) and the kernel itself are "programs that run while the security level is 0" and must be considered part of the TCB.
 
The following sysctl(3) variables are exported:
security.models.securelevel.securelevel
The system security level. This level may be raised by processes with appropriate privilege. It may only be lowered by process 1 (init).
SEE ALSO
AUTHORS
Elad Efrat <elad@NetBSD.org>
BUGS
Systems without sysctl(8) behave as though they have security level -1.
 
The security level 2 restrictions relating to TCB integrity protection should be enforced at security level 1. Restrictions dependent upon security level but not relating to TCB integrity protection should be selected by sysctl(8) settings available only at security level 0 or lower.