Red Hat Bugzilla – Bug 818198
cgroupfs needs to support labeling/XAttrs
Last modified: 2013-04-23 13:25:11 EDT
Description of problem: We would like to control which processes can update certain sections of the cgroupfs. For example a container running as root should get a certain subtree that is is allowed to manage but not be allowed to break out of the container. I think we can do this if cgroupfs supported extended attributes.
Looking briefly at kernel/cgroup.c, I see that: - New inodes are assigned the uid/gid of the creating task. If you wanted to follow that model, you could use fs_use_trans for cgroup and then define type transitions so you could distinguish cgroups created by different domains. That would also allow userspace to set specific security contexts, just like with devpts. Doesn't look like you need a real xattr handler unlike sysfs because the inodes are pinned and there is no "backing store" for inode attributes. - If you write a pid to certain cgroup files, you end up in attach_task_by_pid(), which contains hardcoded uid checks, no capable() calls, and no security hook. So no SELinux-based restrictions there, and euid 0 is all-powerful for cgroups even if no-capabilities? Am I missing something?
I am thinking I want libvirt to label a subtree of the cgroupfs with the appropriate label for a container, and then allow systemd to do its thing within this part of the container. But even though systemd within the container is running as root, block it from mounting cgroupfs or dealing with other parts of the cgroupfs.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Is this still an issue with the 3.9 kernels in F19?
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.