[systemd-devel] User sessions: limit the ability to migrate cgroups
Daniel J Walsh
dwalsh at redhat.com
Fri Aug 15 08:18:53 PDT 2014
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)
>>> 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.
>>> 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.
>>> $ systemd-cgls
>>> Working Directory /sys/fs/cgroup/systemd/user.slice/user-1000.slice:
>>> │ ├─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
> 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.
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
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
Which is the default label of the cgroup file system. No confined/Few
domains right now should be allowed to write to cgroupfs_t.
More information about the systemd-devel