skip to content W3C SVG

Secure levels

There are 4 security levels in OpenBSD, that can only be increased on a running system, never decreased:

  • -1: Permanently insecure mode:
    • init(8) will not attempt to raise the securelevel
    • may only be set with sysctl(8) while the system is insecure
    • otherwise identical to securelevel 0
  • 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 cannot be opened
    • raw disk devices of mounted file systems are read-only
    • system immutable and append-only file flags may not be removed
    • the fs.posix.setuid, hw.allowpowerdown, kern.allowkmem, net.inet.ip.sourceroute, and machdep.kbdreset sysctl(8) variables may not be changed
    • the ddb.console, ddb.panic, and machdep.allowaperture sysctl(8) variables may not be raised
    • gpioctl(8) may only access GPIO pins configured at system startup
  • 2: Highly secure mode:
    • all effects of securelevel 1
    • raw disk devices are always read-only whether mounted or not
    • settimeofday(2) and clock_settime(2) may not set the time backwards or close to overflow
    • pf(4) filter and NAT rules may not be altered

The only relevant securelevel is the level 2, since level -1 and 0 are useless security-wise, and level 1 is the (sane) default one.

As said in its documentation:

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.

All of this is just one kernel-exploit away from being rolled-back. Also, those actions aren’t preventing data exfiltration since they aren’t hindering an attacker’s read capabilities. Since raising the securelevel is a manual action, it doesn’t act as a deterrent either: an attacker can relaunch their exploit as much as they want until they get root, the securelevel won’t be automatically raised. I fail to come up with a single use case for them, and apparently I’m not the only one:

Joshua Stein, an OpenBSD’s developer, said in August 2018 about them:

securelevels are not really used much anymore. I don’t think any new code has used them (as far as changing behavior based on the securelevel) in quite a long time.

Even Theo de Raadt himself replied in
December 2005, to a security advisory about a trivial bypass of a securelevel’s restriction:

“Sorry, we are going to change nothing. Securelevels are useless.”

So much for not keeping useless legacy code around, especially in the kernel.