Re: [systemd-devel] Regression in v40? User session inside a unit.
On Fri, 09.03.12 10:14, Colin Guthrie (gm...@colin.guthr.ie) 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). 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). Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Regression in v40? User session inside a unit.
'Twas brillig, and Lennart Poettering at 12/03/12 13:07 did gyre and gimble: On Fri, 09.03.12 10:14, Colin Guthrie (gm...@colin.guthr.ie) 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 systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Regression in v40? User session inside a unit.
'Twas brillig, and Lennart Poettering at 05/03/12 18:12 did gyre and gimble: On Mon, 20.02.12 01:27, Colin Guthrie (gm...@colin.guthr.ie) wrote: Hi, Not sure if this is an intended regression or not but a user reported a problem to me recently which I thought was a little strange. It's maybe been fixed already in newer versions (we were in a beta semi-freeze and I've been on holiday so not updated to v43 yet but will do soon). Anyway the problem was the unit was run as root (no User=) but that ultimately ran a perl script that then invoked su to switch to the apache user. While this is obviously not needed (better to use User=apache), it did result in the user session cgroup (name=systemd:/user/apache/c59) overriding the unit cgroup (name=systemd:/system/zoneminder.service) and thus systemd could no longer see the processes the service started (and thus didn't kill them on systemctl stop zoneminder.service) If using su is all that is needed to escape the unit cgroup, then it could be a little bit ambiguous for a user trying to find all processes started by a given service. Hopefully, this has been fixed already, or perhaps documented somewhere I missed (I didn't see it in http://www.freedesktop.org/wiki/Software/systemd/PaxControlGroups) 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? 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 systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Regression in v40? User session inside a unit.
On Mon, 20.02.12 01:27, Colin Guthrie (gm...@colin.guthr.ie) wrote: Hi, Not sure if this is an intended regression or not but a user reported a problem to me recently which I thought was a little strange. It's maybe been fixed already in newer versions (we were in a beta semi-freeze and I've been on holiday so not updated to v43 yet but will do soon). Anyway the problem was the unit was run as root (no User=) but that ultimately ran a perl script that then invoked su to switch to the apache user. While this is obviously not needed (better to use User=apache), it did result in the user session cgroup (name=systemd:/user/apache/c59) overriding the unit cgroup (name=systemd:/system/zoneminder.service) and thus systemd could no longer see the processes the service started (and thus didn't kill them on systemctl stop zoneminder.service) If using su is all that is needed to escape the unit cgroup, then it could be a little bit ambiguous for a user trying to find all processes started by a given service. Hopefully, this has been fixed already, or perhaps documented somewhere I missed (I didn't see it in http://www.freedesktop.org/wiki/Software/systemd/PaxControlGroups) 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. Thanks, Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
