- A Tale of Two Security Models
- Building a Good Security System
- SELinux and Systrace
- So Whats the Answer?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
SELinux and Systrace
One development that has been getting a lot of press recently is SELinux, which adds role-based access control to Linux. Since it first shipped with Fedora Core, I’ve seen a large number of support exchanges with users that have gone something like this:
User: "Something’s not working on my Fedora machine!"Helper: "Try turning off SELinux."
User: "Ah, it works now, thanks!"
The correct next step, of course, is for the user to track down why the particular app wasn’t working with SELinux enabled, modify the affected policy accordingly (or fix the code), and then turn SELinux back on. Somehow, I suspect that this step is often ignored.
The Systrace mechanism, found on OpenBSD and NetBSD, works in the opposite direction. Unlike SELinux, Systrace must be run on a per-process basis. The advantage of this arrangement is that if something doesn’t work with Systrace, the user only needs to disable it for that one app, not system-wide. In spite of this advantage, I suspect that, like SELinux, Systrace is rarely used in cases where a policy is not supplied along with the application.
Systrace, along with the rest of the OpenBSD philosophy when it comes to security, tells us one thing: People will run secure systems if they’re easy to secure. By default, an OpenBSD system runs programs at the lowest privilege possible, and even runs some programs in a chroot environment. By and large, these services remain secure, because the user doesn’t need to do anything to ensure that they do.