*BSD "securelevel" [LWN.net]

*BSD "securelevel"

Posted Mar 14, 2013 10:03 UTC (Thu) by ewen (subscriber, #4772)
Parent article: The trouble with CAP_SYS_RAWIO

Reading through this article reminded me of *BSDs "securelevel", which is a one-way ratchet change (ie having changed it, you can't change it back to a less secure level except by rebooting). It controls various "compromise the kernel" like things. The exact set of things it controls is probably not an ideal match, but the idea of a sysctl value which can only ever be changed to "be at least as restrictive of insecure things you can do as now" seems like a fairly good fit. And it would be completely orthogonal to the Linux capabilities, which seems helpful. (As well as being "system wide" which seems desirable in this case -- if you've booted via secure UEFI you probably don't want to end up in a situation where some processes can compromise the kernel and others cannot....)

Ewen

(Log in to post comments)

*BSD "securelevel"

Posted Mar 14, 2013 11:40 UTC (Thu) by spender (subscriber, #23067) [Link]

Linux already attempts this a bit inconsistently. See /proc/sys/kernel/modules_disabled, which does not allow module loading to be re-enabled once disabled. Yet you can just run: https://grsecurity.net/~spender/msr32.c (before it required no capabilities, now it requires CAP_SYS_RAWIO, but neither matter) and re-enable the supposed securelevel-like value. There is no CVE for this (only for the adding of CAP_SYS_RAWIO) and no patch for the removal of modules_disabled on x86. There's no coherency to upstream security.

-Brad

*BSD "securelevel"

Posted Mar 14, 2013 16:39 UTC (Thu) by ThinkRob (subscriber, #64513) [Link]

At the risk of going slightly off-topic (though not much, given the matter at hand), what do you think of FreeBSD's approach to kernel security? I'd be willing to wager you're a fan of the fact that (it seems like) they're a bit more up-front with their security hole disclosure, but what about things like the "secure level" model, jails, capsicum, and other security-oriented features they've introduced -- do you think they're on the right track?

I know the full answer to this is probably not terribly succinct, but I'm just curious to hear what you think, since kernel security is obviously something you're quite passionate about. :)

*BSD "securelevel"

Posted Mar 20, 2013 9:13 UTC (Wed) by renox (subscriber, #23785) [Link]

Is capsicum actually used in FreeBSD?
AFAIK it's only useful iff programs are ported to use it..

*BSD "securelevel"

Posted Mar 14, 2013 18:35 UTC (Thu) by ewen (subscriber, #4772) [Link]

Which is an important point: if you're going to implement something like this, it needs to be sufficiently encompassing (in the single switch) that it doesn't allow a user (or attacker) to simply undo it by using an alternative mechanism to manipulate the value. The *BSD "securelevel" handles that by having a single switch that cuts off a set of things, including raw memory manipulation and module loading.

It sounds like the "compromise the kernel" flag is also aimed to cut off a more encompassing set of things, so hopefully it'd be less easy to do an end-run around the protection. (And there'd be more incentive to add "you can't do that either" into the set of things turned off as other ways to manipulate it are discovered: Firewire device DMA being one that comes to mind.)

Ewen

*BSD "securelevel"

Posted Mar 19, 2013 22:33 UTC (Tue) by wahern (subscriber, #37304) [Link]

There are enough issues w/ BSD securelevel, too, that it doesn't receive much interest these days.

For example, the immutable files protection can be bypassed by mounting over the directory. It doesn't allow you to change the original file, but allows you to fool other applications at runtime and is thus of little use for, e.g., preventing root kit installation once you've already attained root.

AFAIK nobody has bothered to fix it on systems where it was an issue (NetBSD was immune to this particular attack). The fundamental issue is that even this course-grained capabilities system gives a false of security. Invariably someone will forget about some corner case, or some new feature is added which allows circumvention of the whole pile of policies.

Fine-grained capabilities systems (both system-level and process-level) are just too brittle, including the policies, the mechanisms, and the actual implementations.

Unix systems have only just recently reached a decent level of correctness and reliability with basic file permissions. Anybody who relies on more sophisticated schemes (or allows them in their kernel) is just begging to be rooted.