> For the complete documentation index, see [llms.txt](https://book.bsdcn.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://book.bsdcn.org/ask/flat/chapter-29-security/di-29.4-jie-an-quan-deng-ji.md). # 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: ```sh # 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. ```sh # sysrc kern_securelevel=2 ``` The security level will take effect after reboot. View the current security level of the running system: ```sh # 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://book.bsdcn.org/ask/flat/chapter-29-security/di-29.4-jie-an-quan-deng-ji.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.