| |||||||||||||
*BSD "securelevel"*BSD "securelevel"Posted Mar 14, 2013 18:35 UTC (Thu) by ewen (subscriber, #4772)In reply to: *BSD "securelevel" by spender Parent article: The trouble with CAP_SYS_RAWIO
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
(Log in to post comments)
*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.
|
|||||||||||||