29.4 Security Levels

Security levels are a built-in security mechanism of the FreeBSD kernel, viewable via sysctl kern.securelevel. At runtime, the value can only be increased unidirectionally among the five levels from -1 to 3 (it cannot be decreased).

Overview

Security levels are a built-in kernel security mechanism. When the security level is positive, the kernel restricts certain operations, even for the root user.

The security level mechanism restricts the following capabilities:

• Unsetting certain file flags, such as schg (system immutable flag).
• Writing to kernel memory through /dev/mem and /dev/kmem.
• Loading kernel modules.
• Changing firewall rules.

Security Level Definitions

The kernel defines five security levels. Any superuser process can raise the level, but no process can lower it.

The definitions of each security level are as follows:

Level	Name	Description
-1	Permanently Insecure Mode	The system is always in insecure mode. This is the default initial value.
0	Insecure Mode	Immutable and append-only flags can be turned off. All devices can be read and written according to their permissions.
1	Secure Mode	System immutable and system append-only flags cannot be turned off; disks with mounted file systems, /dev/mem, and /dev/kmem cannot be opened for writing; if the platform has /dev/io, opening it is completely prohibited; kernel modules cannot be loaded or unloaded. Entering the kernel debugger via sysctl debug.kdb.enter is prohibited (unless access is granted by a MAC(9) policy, such as mac_ddb(4)); forcing a panic or trap via debug.kdb.panic, debug.kdb.panic_str, and other sysctls is also not possible.
2	Highly Secure Mode	In addition to secure mode restrictions, disks (whether mounted or not) cannot be opened for writing, except for mount operations. This level prevents data tampering by unmounting file systems, but also means newfs cannot be run in multi-user mode. Additionally, kernel time changes are limited to no more than 1 second; modifications exceeding this range will generate the log message "Time adjustment clamped to +1 second".
3	Network Secure Mode	In addition to highly secure mode restrictions, IP packet filtering rules (ipfw(8), ipfw(4), and pfctl(8)) cannot be modified, and dummynet(4) or pf(4) configurations cannot be adjusted.

The key difference between permanently insecure mode and insecure mode is that the former completely removes all security restrictions, while the latter, although relaxing some constraints, still retains a considerable degree of control.

According to the way init(8) works, if the system's initial security level is 0, init will raise it to 1 before first entering multi-user mode. Since the security level can only be raised and not lowered, even after returning to single-user mode, the system will maintain at least level 1. Additionally, setting the security level to a value greater than 1 too early in the boot process may prevent fsck(8) from repairing inconsistent file systems, so it is recommended to set it at the end of /etc/rc (after all multi-user startup operations have completed).

Modifying the Security Level

First, ensure that the security level setting is enabled:

# sysrc kern_securelevel_enable="YES"

Then set kern.securelevel to the desired security level (allowed values range from -1 to 3):

Warning

The security level can only be raised, not lowered. Once set, if you need to revert, you must restart the system and modify it in single-user mode. In remote management scenarios, an excessively high security level may restrict disk writes, kernel module loading, and other operations, making normal maintenance impossible. It is recommended to verify the impact in a test environment before applying it to production.

# sysrc kern_securelevel=2

The security level will take effect after reboot.

View the current security level of the running system:

# sysctl -n kern.securelevel
2

The output is the current value of the security level. If it is greater than 0, it indicates that the system has at least some security protections enabled.

Exercises

1. Set kern.securelevel to 0, 1, and 2 in sequence. At each level, attempt the following operations: delete a file with the schg flag, load a kernel module, and modify kern.securelevel itself. Create a table summarizing whether each operation is allowed or denied at each security level.
2. Explain why the value of kern.securelevel can only be increased and not decreased? From an attacker's perspective, analyze what security threat scenarios would arise if lowering the security level were allowed.
3. Some argue that such security levels are no longer important in modern computer security. State the reasons for this view.