'Twas brillig, and Lennart Poettering at 12/03/12 13:07 did gyre and gimble: > On Fri, 09.03.12 10:14, Colin Guthrie ([email protected]) wrote: > >>>> Perhaps user sessions should be kept under name=logind cgroup tree >>>> rather than reusing name=systemd? That would avoid the problem (although >>>> it could still mean that such spawed processes get killed off if some >>>> config options like kill-session-processes=1 are set I guess, but that >>>> would be the same as currently I suppose). >>> >>> For killing services we generally kill everything in the cgroup plus the >>> main plus the control process (if there is any). We do this to avoid >>> problems with services which are moved to other cgroups. I guess what is >>> missing here is a bit of code in the service listing logic to also >>> include the main/control PID explicitly in the cgroup listing, if it >>> isn't part of the cgroup anyway. >>> >>> I'll add this to the TODO list. >> >> >> Sorry for asking a potentially silly question, but one of the things I >> thought systemd was good for was to track all the processes spawned by a >> given service. >> >> An early example I remember reading was that processes spawned from an >> apache CGI could all be seen, thus if there was an intrusion, you could >> easily kill all processes. >> >> If all that is needed to escape this cgroup is to issue a su command >> (something that a large proportion of intrusions will likely try!) does >> this not reduce the usefulness of this cgroup tracking? >> >> Or is this really not a security feature at all? Am I misremembering the >> original examples or are they just not as powerful as I had hoped? > > It is a security feature. However, what is key here is that leaving a > control group is a privileged operation. That's how things work on Unix: > if you are root you can do whatever you want. You have the right to > ptrace anything, you can dump the whole system memory, you have the full > power over everything. On Unix, there is no further access control > enforced if you managed to become root, and that does make a lot of > sense that way (well, with capabilities you can make root privs more > finegrained, but that's besides the point, because to be true root you > have all caps).
Ahh I see, so the only reason my test case could "escape" the cgroup is because it was obviously root at the time it made a run for it. Now that it's properly got the User=apache declaration in the unit, issuing further su commands will not result in any escape. > If you want more complex access control, and disallow certain services > to change the cgroup assignment even with UID=0 then technologies such > as SELinux are the right choice. However on the user software level it > makes little sense to try to limit access control for root in any way > (or, for the matter between processes of the same uid). OK, I think I understand. 1. An process run as "beefy" user, turns out to be exploitable. 2. An exploit is able to run su and guesses the root password of "miracle" and creates a root process. 3. At this stage that root process is still in the service cgroup, but if they issue a further su or manually fiddle with the cgroups, they will escape it. So I guess this is where you would want to employ something like SELinux. Cheers for the explanation. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
