securelevel —
securelevel and its effects
The
OpenBSD kernel provides four levels of system
security:
-
-
- -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
Securelevel provides convenient means of “locking down” a system
to a degree suited to its environment. It is normally set at boot by
rc(8), or the superuser may raise
securelevel at any time by modifying the
kern.securelevel
sysctl(8) variable. However,
only
init(8) may lower it once the
system has entered secure 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.
- /etc/rc.securelevel
- commands that run before the security level changes
init(8),
rc(8),
sysctl(8)
The
securelevel manual page first appeared in
OpenBSD 2.6.
The list of securelevel's effects may not be comprehensive.
![[OpenBSD]](/openbsd.gif){kind=small}