On Wed, 13 Aug 2014 16:37:17 +0200 Lennart Poettering <[email protected]> wrote:
> On Thu, 07.08.14 15:19, Alban Crequy ([email protected]) > 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 [email protected]/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 [email protected] > service, but keep it restricted otherwise... It makes sense. > > So processes can freely move from session-c4.scope to > > [email protected]. 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@pts/2 > > │ ├─723 -bash > > │ ├─732 systemd-cgls > > │ └─733 pager > > ├─[email protected] > > │ ├─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 [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
