Introduction

Kernel security levels have been introduced back in 4.4 to use file flags as a mechanism to enhance security. Ususally the system is running at a level 1, which can be checked with sysctl kern.securelevel, once the level has been set in the bootup process using the securelevel option in /etc/rc.conf you cannot lower the level anymore, but you are allowed to raise it to either 1 or 2.

The ?sysctl variable kern.securelevel is a variable that is usually -1 or 0, and can be raised during normal operation to disallow certain operations in the filesystem to increase security.

Securelevel restrictions

secmodel_bsd44(9) defines the following restrictions:

-1 Permanently insecure mode

Don't raise the securelevel on boot

0 Insecure mode

The init process (PID 1) may not be traced or accessed by ptrace(2), systrace(4), or procfs.
Immutable and append-only file flags may be changed
All devices may be read or written subject to their permissions

Note: You can't run X11 with legacy (e.g. VESA) drivers above this securelevel

Try sysutils/aperture if you really need it.

1 Secure mode

All effects of securelevel 0
/dev/mem and /dev/kmem may not be written to
Raw disk devices of mounted file systems are read-only
Immutable and append-only file flags may not be removed
Kernel modules may not be loaded or unloaded
The net.inet.ip.sourceroute sysctl(8) variable may not be changed
Adding or removing sysctl(9) nodes is denied
The RTC offset may not be changed
Set-id coredump settings may not be altered
Attaching the IP-based kernel debugger, ipkdb(4), is not allowed
Device ``pass-thru requests that may be used to perform raw disk and/or memory access are denied
iopl and ioperm calls are denied
Access to unmanaged memory is denied

2 Highly secure mode

All effects of securelevel 1
Raw disk devices are always read-only whether mounted or not
New disks may not be mounted, and existing mounts may only be downgraded from read-write to read-only
The system clock may not be set backwards or close to overflow
Per-process coredump name may not be changed
Packet filtering and NAT rules may not be altered

Examining and changing securelevel

As a user, you can see the current value of securelevel:

$ sysctl kern.securelevel
kern.securelevel = -1

But of course, you cannot change it:

$ sysctl -w kern.securelevel=0
sysctl: kern.securelevel: sysctl() failed with Operation not permitted

You need to be root to do that:

# sysctl -w kern.securelevel=1
kern.securelevel: -1 -> 1

Once it is set, its value can never be set to a lower value again:

# sysctl -w kern.securelevel=-1
sysctl: kern.securelevel: sysctl() failed with Operation not permitted

... except by the kernel debugger, which you can enter at the console. On i386, press ++:

db> w/l securelevel (-1)
netbsd:securelevel   0x1 -> 0xffffffff
db> c

Setting securelevel permanently

The securelevel can be set after booting the system by setting the securelevel shell variable in /etc/rc.conf (see ?manpage).