Understanding FreeBSD Securelevels

Securelevel -1: Permanently Insecure

• Description:
  This mode disables the securelevel mechanism entirely. The system will never automatically raise the securelevel after boot.

• Features:

• root can always modify or remove system flags such as schg (system immutable).

• Kernel modules can be loaded or unloaded at any time.
• Raw disks can be accessed and written without restriction.
• Use case:
  Development machines, test labs, or desktop installations where convenience is more important than strict protection.
• Example:
  A developer running ZFS on a laptop might prefer securelevel -1, so that snapshots, raw device access, or kernel tweaks can be performed without rebooting.
• Undoing:
  To move away from -1, edit /etc/rc.conf or /boot/loader.conf to set a different level.

Securelevel 0: Insecure

• Description:
  This is the default securelevel at boot. The kernel permits almost everything root requests, but the system may later raise the securelevel to 1 if configured.

• Features:

• root can set or clear both uchg (user immutable) and schg (system immutable) flags.

• Kernel modules can be freely loaded and unloaded.
• Raw disks can be read or written.
• Use case:
  General-purpose servers and workstations where administration flexibility is required, but you might still want to raise the level manually later.
• Example:
  On a web server, the administrator can lock critical binaries with schg after the boot process. If securelevel remains 0, these flags can still be removed later if updates are needed.

Undoing changes is trivial in this mode:

chflags noschg /bin/ls

will succeed without requiring single-user mode.

Securelevel 1: Secure

• Description:
  Once set, the system enters secure mode. Some operations that could alter the system integrity are now blocked, even for root.

• Features:

• Files marked schg cannot have their flags removed in multi-user mode.

• Direct writing to raw disk devices (except for mounted swap) is denied.
• Loading or unloading of kernel modules may be restricted depending on configuration.
• Use case:
  Production servers, firewalls, or appliances where you want to ensure binaries and configs cannot be silently altered.
• Example:
  Suppose /etc/passwd is flagged with schg. On a securelevel 1 system, no attacker—even with root access—can modify or delete it without rebooting into single-user mode. This makes persistence of an intrusion harder.

To undo an immutable flag in this state, you must:

1. Reboot into single-user mode.
2. Remount the filesystem as read-write:

sh mount -u / mount -a
3. Clear the flag:

sh chflags noschg /etc/passwd

Securelevel 2: Highly Secure

• Description:
  This level builds upon securelevel 1 but introduces stricter restrictions around raw device access and clock manipulation.

• Features:

• All restrictions of level 1.

• Even in single-user mode, raw disk writes to mounted filesystems are prohibited.
• The system clock cannot be moved backward, only forward (to prevent log tampering).
• Use case:
  Environments requiring strong guarantees of integrity, such as financial systems, audit servers, or bastion hosts.
• Example:
  An audit log server set to securelevel 2 ensures that logs cannot be altered retroactively. Even if an attacker gets root, they cannot roll back the system time or overwrite parts of the log device.

Undoing restrictions at this level typically requires rebooting with a different kernel boot option or reducing the securelevel explicitly before reaching multi-user mode.

Securelevel 3 and Above

FreeBSD supports levels greater than 2, but they are rarely used. The documentation defines them as extensions of the "highly secure" model, sometimes with device-specific restrictions. In practice, most administrators stop at 2.

How to Configure or Change Securelevels

• Check current securelevel:

  sysctl kern.securelevel

• Set at runtime (can only be raised, not lowered, unless already -1):

  sysctl kern.securelevel=1

• Set permanently at boot:
  In /etc/rc.conf:

  kern_securelevel_enable="YES"
  kern_securelevel="1"

In /boot/loader.conf:

kern.securelevel=1

• Undoing:
  If the system has moved to a higher securelevel, the only way to lower it is a reboot into single-user mode (unless the machine was booted at -1).

Using Immutable Flags

Once you know how securelevels work, the most practical application is to lock files and directories against accidental or malicious modifications. FreeBSD provides two flags for this:

• uchg → user immutable (easy to set/unset as root)
• schg → system immutable (honored according to securelevel, harder to undo)

Make a single file immutable

sudo chflags uchg /etc/hosts

Now the file cannot be modified or deleted until the flag is removed.
To check the status:

ls -lo /etc/hosts

You’ll see the uchg flag listed.
To remove it:

sudo chflags nouchg /etc/hosts

Protect an entire folder (only the folder itself)

sudo chflags uchg /var/log

This prevents renaming or removing the folder, but you can still create or delete files inside it.

Protect a folder and all its contents (recursively)

sudo chflags -R uchg /var/log

Now both the folder and every file/subfolder within it are immutable. Attempts to rotate or delete logs will fail until the flag is removed.

To undo recursively:

sudo chflags -R nouchg /var/log

Using schg for stronger protection

If you need a system-level lock (useful on production systems with securelevel ≥ 1):

sudo chflags schg /etc/passwd

At securelevel 1, even root cannot clear this flag in multi-user mode. The only way to remove it is to reboot into single-user mode and run:

chflags noschg /etc/passwd

This combination of securelevels and immutable flags allows you to decide how “hard” your protections should be: convenient and flexible with uchg, or enforced by the kernel with schg.

Conclusion

Securelevels are a powerful tool in FreeBSD for limiting the potential damage an intruder—or even an administrator—can cause once the system is running. They complement traditional access control with kernel-enforced guarantees. Choosing the right level depends on your balance between flexibility and security.

Here is a summary table for quick reference:

| Securelevel | Mode Name             | Main Protections                           | Typical Use Case                         | Undoing Restrictions       |
| ----------- | --------------------- | ------------------------------------------ | ---------------------------------------- | -------------------------- |
| -1          | Permanently insecure  | No restrictions; `root` can always unset   | Development, desktop, test lab           | Trivial (`chflags noschg`) |
|             |                       |    `schg`, load modules, write raw disks   |                                          |                            |
| ----------- | --------------------- | ------------------------------------------ | ---------------------------------------- | -------------------------- |
| 0           | Insecure (default)    | Like `-1`, but system may later raise      | General-purpose servers, flexible setups | Trivial (`chflags noschg`) |
|             |                       | securelevel                                |                                          |                            |
| ----------- | --------------------- | ------------------------------------------ | ---------------------------------------- | -------------------------- |
| 1           | Secure                | Cannot clear `schg` in multi-user, blocks  | Firewalls, production servers            | Reboot → single-user mode  |
|             |                       | raw disk writes, limits kernel changes     |                                          |                            |
| ----------- | --------------------- | ------------------------------------------ | ---------------------------------------- | -------------------------- |
| 2           | Highly secure         | All of level 1 + no raw writes to mounted  | Audit servers, financial systems         | Reboot with lower level    |
|             |                       | FS even in single-user; cannot set clock   |                                          |                            |
|             |                       | backward                                   |                                          |                            |
| ----------- | --------------------- | ------------------------------------------ | ---------------------------------------- | -------------------------- |
| 3+          | Extended restrictions | Rarely used, vendor/device specific        | Special appliances                       | Reboot with lower level    |
| ----------- | --------------------- | ------------------------------------------ | ---------------------------------------- | -------------------------- |

Would you like me to also add a practical demo section (commands showing chflags schg on a file, then what happens at each securelevel) so readers can experiment safely on their machines?