MirBSD manpage: securelevel(7)

SECURELEVEL(7)               BSD Reference Manual               SECURELEVEL(7)


     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

      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 filesystems 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 net.inet.ip.sourceroute sysctl(8) variable may not be
           -   the machdep.kbdreset sysctl(8) variable may not be changed

      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 back-
               wards or close to overflow
           -   pf(4) filter and NAT rules may not be altered
           -   the ddb.console and ddb.panic sysctl(8) variables may not be
           -   Filesystems may neither be mounted nor umounted. (Maybe other
               operations should be denied, too.)
           -   Writes to the random number generator devices, namely
               /dev/srandom, /dev/urandom and /dev/arandom, are prohibited, as
               well as several IOCTLs. The addpool is still processed (there
               is an extra sysctl to disable it) and can be filled from user-
               land by writing to the KERN_ARND sysctl; init(8) is permitted
               to add to arandom and restir.


     Securelevel provides convenient means of "locking down" a system to a de-
     gree 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 kern.securelevel 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. (Setting the securelevel to -1 in /etc/rc.securelevel has
     the same effect.)

     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 filesystem 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 be-
     ing set backwards aids in post-mortem analysis and helps ensure the in-
     tegrity 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 on highly
     secure systems. 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


     chflags(2), settimeofday(2), mem(4), options(4), init(8), rc(8),


     The securelevel manual page first appeared in OpenBSD 2.6.

     Mounting was disallowed in highly secure mode in MirBSD #9.


     Securelevels defend against a compromisal of the root account. The 4.4BSD
     kernel however is not designed for such thing, thus, securelevels should
     only be used as a tool for convenience, not be seen as an actual security


     The list of securelevel's effects may not be comprehensive.

MirBSD #10-current             August 25, 2019                               1

Generated on 2022-12-24 01:00:14 by $MirOS: src/scripts/roff2htm,v 1.113 2022/12/21 23:14:31 tg Exp $ — This product includes material provided by mirabilos.

These manual pages and other documentation are copyrighted by their respective writers; their sources are available at the project’s CVSweb, AnonCVS and other mirrors. The rest is Copyright © 2002–2022 MirBSD.

This manual page’s HTML representation is supposed to be valid XHTML/1.1; if not, please send a bug report — diffs preferred.

Kontakt / Impressum & Datenschutzerklärung