From mboxrd@z Thu Jan  1 00:00:00 1970
From: sven.vermeulen@siphos.be (Sven Vermeulen)
Date: Tue, 12 Feb 2013 20:47:52 +0100
Subject: [refpolicy] RFC: kernel_t exec rights on cgroup_t files
Message-ID: <20130212194751.GA6803@siphos.be>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

Hi guys,

When cgroups are mounted, we get the following error:

#v+
Feb 12 16:40:21 mygoo kernel: [    7.416048] grsec: mount of cpuacct to /sys/fs/cgroup/cpuacct by /bin/mount[mount:1038] uid/euid:0/0 gid/egid:0/0, parent /lib64/rc/sh/runscript.sh[runscript.sh:1014] uid/euid:0/0 gid/egid:0/0
Feb 12 16:40:21 mygoo kernel: [    7.425020] cgroup_addrm_files: failed to add tasks, err=-13
Feb 12 16:40:21 mygoo kernel: [    7.425024] cgroup_addrm_files: failed to add cgroup.procs, err=-13
Feb 12 16:40:21 mygoo kernel: [    7.425026] cgroup_addrm_files: failed to add notify_on_release, err=-13
Feb 12 16:40:21 mygoo kernel: [    7.425028] cgroup_addrm_files: failed to add cgroup.event_control, err=-13
Feb 12 16:40:21 mygoo kernel: [    7.425030] cgroup_addrm_files: failed to add cgroup.clone_children, err=-13
Feb 12 16:40:21 mygoo kernel: [    7.425032] cgroup_addrm_files: failed to add release_agent, err=-13
Feb 12 16:40:21 mygoo kernel: [    7.425038] SELinux: initialized (dev cgroup, type cgroup), uses genfs_contexts
#v-

It seems that, when adding the files in the cgroup locations, somewhere in
the chain the EXEC rights are checked. If they fail, then the flow stops
with a ENOACCESS error.

cgroup_addrm_files
`- cgroup_add_file
   `- lookup_one_len
      `- inode_permission(base->d_inode, MAY_EXEC)
         `- __inode_permission
	    (etc)

Adding something like "allow kernel_t cgroup_t:file exec_file_perms;" is
sufficient to stop the errors from coming up, but I'm having a few doubts:

- Why does it check MAY_EXEC in order to add files? 
- Why does it work to allow this on the /file/ class whereas I think the
  MAY_EXEC is on the directory?

Is it the right road to go to look for the least privilege to grant on
kernel_t for this (audit_access I think?) Or should this be handled
differently?

Wkr,
	Sven Vermeulen

PS Thanks to Luis Ressel for debugging this this far.