SECMODEL_SECURELEVEL(9)

💅 SECMODEL_SECURELEVEL — the securelevel security model, explained by your personal Unix bestie

okay so real talk, this is page SECMODEL_SECURELEVEL(9) from the Kernel Developer's Manual, and it's genuinely one of those pages that sounds scary but is actually just "how do we lock the system down so even root can't mess with it." stay with me 🫶

---

✨ NAME ✨

secmodel_securelevel — the securelevel security model, aka the vibe-check enforcer for your kernel 🔥

---

🌸 DESCRIPTION 🌸

so the whole securelevel thing exists for one iconic reason: it protects the persistence of code and data on your system (or some subset of it 🎀) so that nobody can modify it — and yes, we mean even the super-user 😭. it gives you a convenient way to "lock down" a machine to a degree that matches its environment. it's giving vault door energy. no cap.

the super-user can raise the securelevel using sysctl(8), but here's the tea: only init(8) can lower it. one-way ratchet, bestie. 🦋

there are four security levels, and they stack like a fit:

🍓 -1 — Permanently insecure mode

• Do not raise the securelevel on boot.

🍓 0 — Insecure mode

• The init process (PID 1) may not be traced or accessed by ptrace(2) or procfs.
• Immutable and append-only file flags may be changed by chflags(1) or by other means.
• All devices may be read or written subject to their permissions.
• All gpio(4) pins can be set and device drivers can be attached to them.
• On architectures that support module(7), kernel modules can be loaded and unloaded.

⭐ 1 — Secure mode

• All effects of securelevel 0.
• The x86/kmem(4) memory files /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.
• Neither the net.inet.ip.sourceroute nor the vm.user_va0_disable sysctl(8) variables may 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.
• Device "pass-thru" requests that may be used to perform raw disk and/or memory access are denied.
• The iopl and ioperm calls are denied.
• Access to unmanaged memory is denied.
• Only GPIO pins that have been set at securelevel 0 can be accessed.

👑 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.
• CPU ucode loading is denied on platforms that support it.

---

highly secure mode may seem Draconian, but bestie, that's the whole point — it's the last line of defence for when the super-user account gets compromised 😭😭. its effects preclude circumvention of file flags by directly modifying a raw disk device, or erasing a file system via newfs(8). also it can limit the potential damage of a compromised "firewall" by prohibiting modification of packet filter rules. and keeping the system clock from being set backwards aids in post-mortem analysis and helps ensure the integrity of logs. precision timekeeping is not affected, because the clock may still be slowed. slay. ⏰

so normally the system runs in securelevel 0 while single-user and securelevel 1 while multi-user. if you want a higher securelevel while running multi-user, you can set it with the securelevel keyword in the startup script /etc/rc.conf, see rc.conf(5) for deets. lower securelevels require the kernel to be compiled with options INSECURE, which makes it always default to securelevel -1. 🙈

for this protection to actually be effective, the administrator must ensure that no program run while the security level is 0 or lower — nor any data or configuration file used by any such program — can be modified while the security level is greater than 0. this is the part people skip and then get surprised pikachu face 💀

you can achieve that through careful use of the "immutable" file flag to define and protect a Trusted Computing Base (TCB) made up of all such programs and data, or by ensuring all such programs and data live on filesystems mounted read-only while running at security level 2 or higher. and particular care must be taken, if you're relying on security level 1 plus file flags, to ensure the TCB's integrity can't be compromised via modifications to the disklabel or access to overlapping disk partitions — including the raw partition. 👀

and do not overlook the fact that shell scripts (or anything else fed to an interpreter, through any mechanism) and the kernel itself are "programs that run while the security level is 0" and must be considered part of the TCB. literally cannot stress this enough. 🧚

the following sysctl(3) variables are exported:

• security.models.securelevel.securelevel — the system security level. this level may be raised by processes with appropriate privilege. it may only be lowered by process 1 (init). 👑

---

🎀 FUNCTIONS 🎀

secmodel_securelevel exposes a secmodel_eval(9) evaluation routine so you can test whether the current securelevel is above a certain threshold level or not. super handy, iykyk.

the parameters to secmodel_eval(9) are:

• id — the unique identifier of secmodel_securelevel: "org.netbsd.secmodel.securelevel".
• what — a string, "is-securelevel-above".
• arg — a reference to an int representing the threshold level.
• ret — a boolean, set by secmodel_securelevel to true when the securelevel is strictly above the threshold level, false otherwise.

---

🌈 RETURN TYPES 🌈

if successful, the evaluation returns 0 with the ret argument being either true or false. that's it, that's the whole thing. ✨

---

💜 SEE ALSO 💜

kauth(9), secmodel(9), secmodel_bsd44(9), secmodel_eval(9) — go read them, they're the friends of this page fr fr 🫶

---

🌸 AUTHORS 🌸

Elad Efrat <elad@NetBSD.org> — thank you for your service, icon 👑

---

💀 BUGS 💀

• Systems without sysctl(8) behave as though they have security level -1. not me finding that out the hard way 😭
• The security level 2 restrictions relating to TCB integrity protection should be enforced at security level 1.
• Restrictions dependent upon security level but not relating to TCB integrity protection should be selected by sysctl(8) settings available only at security level 0 or lower.

---

<aqua>and that's the page, bestie!! this one came from Debian, dated May 18, 2019 — go forth and lock your systems down responsibly 💅✨🎀</aqua>