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
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
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
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:
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.
“Sorry, we are going to change nothing. Securelevels are useless.”
So much for not keeping useless legacy code around, especially in the kernel.