[systemd-devel] Regression in v40? User session inside a unit.

[Colin Guthrie]

'Twas brillig, and Lennart Poettering at 12/03/12 13:07 did gyre and gimble:
> On Fri, 09.03.12 10:14, Colin Guthrie (gmane at 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/