|
|
Subscribe / Log in / New account

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.


to post comments

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.


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