[systemd-devel] User sessions: limit the ability to migrate cgroups

[Daniel J Walsh]

On 08/13/2014 12:11 PM, Alban Crequy wrote:
> On Wed, 13 Aug 2014 16:37:17 +0200
> Lennart Poettering <lennart at poettering.net> wrote:
>
>> On Thu, 07.08.14 15:19, Alban Crequy (alban.crequy at collabora.co.uk)
>> wrote:
>>
>>> Hi,
>>>
>>> Should unprivileged processes be allowed to change cgroup?
>> Well, they shouldn#t do it. But I think it's OK as long as this is
>> only done within the specific user's hierarchies.
>>
>>> As I understand it, it is not possible to block processes to
>>> leave a cgroup, but only to block processes to enter a cgroup.
>> Correct.
>>
>>> In the following example, session-c4.scope/tasks belongs to
>>> root:root with -rw-r--r-- and user at 1000.service/tasks belongs to
>>> user:user with -rw-r--r--.
>> Yes, this is because systemd --user needs to be able to manage its own
>> cgroup subtree, so we have to open this up for the user at 1000.service
>> service, but keep it restricted otherwise...
> It makes sense.
>
>>> So processes can freely move from session-c4.scope to
>>> user at 1000.service. But not in the other direction.
>> Correct.
>>> $ systemd-cgls
>>> Working Directory /sys/fs/cgroup/systemd/user.slice/user-1000.slice:
>>> ├─session-c4.scope
>>> │ ├─713 sshd: user [priv]  
>>> │ ├─722 sshd: user at pts/2   
>>> │ ├─723 -bash
>>> │ ├─732 systemd-cgls
>>> │ └─733 pager
>>> ├─user at 1000.service
>>> │ ├─406 /lib/systemd/systemd --user
>>>
>>> With user sessions managed by systemd, will it be possible to
>>> restrict unprivileged users from migrating to other cgroups?
>> Unlikely. Access control on Unix is generally bound to user IDs, not
>> processes, and we really shouldn't start here with departing from
>> that...
> I tested SELinux and AppArmor to restrict /sys/fs/cgroup/.
>
> SELinux didn't help because the cgroup file system does not support
> extended attributes such as "security.selinux", but AppArmor was able
> to block an application from changing cgroup.
>
> Alban
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
You could mount the cgroup with a label that the intended domain could
not write.  Similarly you could just prevent the domain from writing to
cgroupfs_t.

Which is the default label of the cgroup file system.   No confined/Few
domains right now should be allowed to write to cgroupfs_t.