securelevel and its effects
The OpenBSD kernel provides four levels of system security:
- -1 Permanently insecure mode
- 0 Insecure mode
- used during bootstrapping and while the system is single-user
- all devices may be read or written subject to their permissions
- system file flags may be cleared with chflags(2)
- 1 Secure mode
- default mode when system is multi-user
- securelevel may no longer be lowered except by init
- /dev/mem and /dev/kmem may not be written to
- raw disk devices of mounted file systems are read-only
- system immutable and append-only file flags may not be removed
- kernel modules may not be loaded or unloaded
- the fs.posix.setuid sysctl(8) variable may not be changed
- the hw.allowpowerdown sysctl(8) variable may not be changed
- the net.inet.ip.sourceroute sysctl(8) variable may not be changed
- the machdep.kbdreset sysctl(8) variable may not be changed
- the ddb.console and ddb.panic sysctl(8) variables may not be raised
- the machdep.allowaperture sysctl(8) variable may not be raised
- gpioctl(8) may only access GPIO pins configured at system startup
- 2 Highly secure mode
Securelevel provides convenient means of “locking
down” a system to a degree suited to its environment. It is normally
set at boot via the
rc.securelevel(8) script, or the superuser may raise
securelevel at any time by modifying the
sysctl(8) variable. However, only
init(8) may lower it once the system has entered secure mode. A
kernel built with
option INSECURE in the config file
will default to permanently insecure mode.
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.
Because securelevel can be modified with the in-kernel debugger ddb(4), a convenient means of locking it off (if present) is provided at securelevels 1 and 2. This is accomplished by setting ddb.console and ddb.panic to 0 with the sysctl(8) utility.
- commands that run before the security level changes
options(4), init(8), rc(8), sysctl(8)
securelevel manual page first appeared
in OpenBSD 2.6.
The list of securelevel's effects may not be comprehensive.