Bug 818198 - cgroupfs needs to support labeling/XAttrs
cgroupfs needs to support labeling/XAttrs
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-02 08:37 EDT by Daniel Walsh
Modified: 2013-04-23 13:25 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-04-23 13:25:11 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Walsh 2012-05-02 08:37:17 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.
Comment 1 Stephen Smalley 2012-05-02 10:29:04 EDT
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?
Comment 2 Daniel Walsh 2012-05-02 11:11:52 EDT
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.
Comment 3 Fedora End Of Life 2013-04-03 11:40:13 EDT
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
Comment 4 Justin M. Forbes 2013-04-05 15:23:40 EDT
Is this still an issue with the 3.9 kernels in F19?
Comment 5 Justin M. Forbes 2013-04-23 13:25:11 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.