Bug 818198 - cgroupfs needs to support labeling/XAttrs
Summary: cgroupfs needs to support labeling/XAttrs
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 19
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-05-02 12:37 UTC by Daniel Walsh
Modified: 2013-04-23 17:25 UTC (History)
10 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-04-23 17:25:11 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Daniel Walsh 2012-05-02 12:37:17 UTC
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 14:29:04 UTC
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 15:11:52 UTC
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 15:40:13 UTC
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 19:23:40 UTC
Is this still an issue with the 3.9 kernels in F19?

Comment 5 Justin M. Forbes 2013-04-23 17:25:11 UTC
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.