Debian TC vote on init system coupling

Posted Feb 24, 2014 22:40 UTC (Mon) by javispedro (guest, #83660)
In reply to: Debian TC vote on init system coupling by HelloWorld
Parent article: Debian TC vote on init system coupling

Process fds is one way. If you're going to repeat Lennart's propaganda, you'll have to elaborate a bit more.

I was actually going to say jails, because it is the only way to do it reliably. Then I realized daemons can escape cgroups, so I guess it's not that "reliable" after all...

Debian TC vote on init system coupling

Posted Feb 25, 2014 17:32 UTC (Tue) by michich (guest, #17902) [Link] (1 responses)

Lennart's claim that there is no alternative to cgroups for systemd's needs is his honest technical opinion. Calling it "propaganda" is an insult.

Why don't you (and/or anyone else who says it's possible to do what systemd does using mechanisms other than cgroups) finally prove Lennart wrong by showing us the code of a portable fork of systemd?

Debian TC vote on init system coupling

Posted Feb 28, 2014 10:58 UTC (Fri) by javispedro (guest, #83660) [Link]

Because systemd is much, much more than just daemon management (which is part of the criticism, btw). The parts of systemd related to process management have been reimplemented to death in e.g. openrc (support for both cgroups and jails), launchd ("process groups"), smf, etc.

Debian TC vote on init system coupling

Posted Feb 25, 2014 20:37 UTC (Tue) by fandingo (guest, #67019) [Link] (19 responses)

> Then I realized daemons can escape cgroups[...]

That's quite the bold claim. Do you mind sharing how that's done?

Debian TC vote on init system coupling

Posted Feb 26, 2014 7:43 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

The last paragraph parses weirdly. With the previous sentence, maybe "jails" was intended there?

Debian TC vote on init system coupling

Posted Feb 28, 2014 10:54 UTC (Fri) by javispedro (guest, #83660) [Link] (17 responses)

Any daemon running as root can trivially escape a cgroup. You need something stronger in order to actually ensure "reliability".

Debian TC vote on init system coupling

Posted Feb 28, 2014 11:43 UTC (Fri) by khim (subscriber, #9252) [Link] (6 responses)

Any daemon running as root can trivially escape a cgroup.

Really? Let's exclude explicitly written malicious code (if you run malicious code under root in any UNIX system you are hosed anyway). How does that happen?

You need something stronger in order to actually ensure "reliability".

You need something stronger to run potentially malicious code, sure. But that's totally different task: given kernel's track record you can not even run malicious code from unknown origin under regular user (you need some level of sandboxing like NaCl or seccomp) thus of course systemd does not try to solve that problem.

Debian TC vote on init system coupling

Posted Feb 28, 2014 19:27 UTC (Fri) by vonbrand (subscriber, #4458) [Link] (5 responses)

You can't exclude malicious code, a vulnerability might allow the attacker to execute arbitrary code.

Debian TC vote on init system coupling

Posted Feb 28, 2014 20:00 UTC (Fri) by khim (subscriber, #9252) [Link] (4 responses)

Once you are unrestricted root the game is finished. End of story. You can do whatever you want with a system (using DMA in GPU works just fine for that). There are plenty of ways to restrict root and, surprise, surprise, most of them make it impossible to escape from cgroup as a nice added bonius. But it's not systemd's place to solve that problem. You can not on one hand complain about systemd “feature creep” and on the other hand complain that it does not work as intrusion detection and/or prevention system.

Debian TC vote on init system coupling

Posted Feb 28, 2014 21:57 UTC (Fri) by javispedro (guest, #83660) [Link] (3 responses)

Yes. But now that we've accepted that using cgroups is not actually reliable, we can go back to discussing why the other approaches have been readily rejected. Even ptrace, as ugly and hacky as it is, is as reliable (as long as the processes that are being monitored run under a lower privilege level).

Debian TC vote on init system coupling

Posted Feb 28, 2014 22:24 UTC (Fri) by fandingo (guest, #67019) [Link] (1 responses)

> But now that we've accepted that using cgroups is not actually reliable

I'm still looking for a concrete example of a service process escaping cgroups when using the systemd single-writer that lives in PID 1. The only thing I can come up with is a full kernel exploit, and that breaks everything. Even khim's worst-case scenario of root with unconfined_t, can't escape other processes from service cgroups. The manager will not allow it, and there's no way to replace the manager.

Debian TC vote on init system coupling

Posted Feb 28, 2014 22:35 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

ptrace a process that's running in another cgroup, ask it to exec another copy of you?

Debian TC vote on init system coupling

Posted Feb 28, 2014 23:33 UTC (Fri) by khim (subscriber, #9252) [Link]

Indeed. Cgroups are designed to be unescapable and non-intrusive means of managing process groups thus they are the only logical choice for the init system, but if you don't really care about making usable system and only want to create safe system there are many possibilities. Besides ptrace there are seccomp (and no, not this new fancy seccomp-bpf but plain old seccomp: it's enough, surpisingly enough). You can use it to create completely safe init system. Why this is bad idea left as an excercise for a reader.

Debian TC vote on init system coupling

Posted Feb 28, 2014 16:42 UTC (Fri) by peter-b (guest, #66996) [Link] (6 responses)

> Any daemon running as root can trivially escape a cgroup. You need something stronger in order to actually ensure "reliability".

Why are you running daemons as root?

Debian TC vote on init system coupling

Posted Feb 28, 2014 16:59 UTC (Fri) by fandingo (guest, #67019) [Link] (5 responses)

Most daemons are privileged for a portion of their lifetime, even if it's only to bind to a low numbered port.

Debian TC vote on init system coupling

Posted Feb 28, 2014 18:36 UTC (Fri) by vonbrand (subscriber, #4458) [Link] (4 responses)

You configure the port in the unit file, no privileges in the daemon required at all.

Debian TC vote on init system coupling

Posted Feb 28, 2014 18:50 UTC (Fri) by fandingo (guest, #67019) [Link] (3 responses)

Yes, you can do that with socket activation, but there are two problems. First, not everything supports socket activation. Httpd is an example that keeps a main process running as root.

Second, even some services that do, still run as root. openssh-server supports socket activation, but the main process is still root, and every session has a root process used for permission separation.

Debian TC vote on init system coupling

Posted Feb 28, 2014 19:15 UTC (Fri) by vonbrand (subscriber, #4458) [Link] (2 responses)

Fix them?

At the very least, this reduces the attack surface to a handful of daemons...

Debian TC vote on init system coupling

Posted Feb 28, 2014 21:06 UTC (Fri) by fandingo (guest, #67019) [Link] (1 responses)

I agree. I'd really like to see blanket prohibition on services calling bind(skt). Bound sockets should exclusively come from the init system.

That being said, while the current processes are "root" mostly in name. SELinux (and other LSMs) for the most part have neutered these processes.

The real security threat comes from kernel exploits, and unfortunately, neither changing service users nor using a LSM sandbox helps prevent kernel exploits that much.

Debian TC vote on init system coupling

Posted Feb 28, 2014 23:23 UTC (Fri) by mgb (guest, #3226) [Link]

"Bound sockets should exclusively come from the init system."

And all P2P S/W should be trash-canned.

Not.

P.S. Does systemd support AF_APPLETALK?

Debian TC vote on init system coupling

Posted Feb 28, 2014 16:57 UTC (Fri) by fandingo (guest, #67019) [Link]

Just so we're clear, I'm talking about the new cgroup implementation (single writer) with systemd as the cgroup manager (PID 1).

Short of a kernel exploit, there is no way to move out of cgroups or to a non-allowed cgroup. The cgroup manager won't allow it, and there's no way even a malicious program could kill the cgroup manager and register as a new manager with the kernel because the manager is PID 1, making it unkillable.

Yes, cgroupfs is insecure because it allows arbitrary writers, and you absolutely need something like SELinux to keep the privileged portions of daemons from causing a jailbreak. Fortunately, this mode of operation will disappear soon (at least for those using systemd).

Debian TC vote on init system coupling

Posted Feb 28, 2014 18:57 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (1 responses)

Maybe this is the security flaw being mentioned that Cyberax is questing for? Do you have more details?

Debian TC vote on init system coupling

Posted Feb 28, 2014 20:06 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

It's not a security issue, really.

A root process can simply move itself to another cgroup hierarchy, since it has access to cgroups.

And a single writer model won't really protect against it because a malicious root process can simply ptrace or replace the cgroups manager with a modified version that allows it to do anything.

Additional confinement is needed to fix this problem, in any case. Be it namespaces, SELinux, AppArmor or something else.