Debian TC vote on init system coupling
Debian TC vote on init system coupling
Posted Feb 28, 2014 11:43 UTC (Fri) by khim (subscriber, #9252)In reply to: Debian TC vote on init system coupling by javispedro
Parent article: Debian TC vote on init system coupling
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.
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.
Posted Feb 28, 2014 20:00 UTC (Fri)
by khim (subscriber, #9252)
[Link] (4 responses)
Posted Feb 28, 2014 21:57 UTC (Fri)
by javispedro (guest, #83660)
[Link] (3 responses)
Posted Feb 28, 2014 22:24 UTC (Fri)
by fandingo (guest, #67019)
[Link] (1 responses)
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.
Posted Feb 28, 2014 22:35 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link]
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
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
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling
Debian TC vote on init system coupling