[refpolicy] RFC: kernel_t exec rights on cgroup_t files

From: dominick.grift@gmail.com (Dominick Grift)
To: refpolicy@oss.tresys.com
Subject: [refpolicy] RFC: kernel_t exec rights on cgroup_t files
Date: Tue, 12 Feb 2013 21:00:51 +0100	[thread overview]
Message-ID: <1360699251.2559.42.camel@d30> (raw)
In-Reply-To: <20130212194751.GA6803@siphos.be>

On Tue, 2013-02-12 at 20:47 +0100, Sven Vermeulen wrote:
> 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?
> 

Not sure, but instead does it work if you add the following rules?:

dontaudit kernel_t cgroup_t:file execute;
allow kernel_t cgroup_t:file audit_access;

> Wkr,
> 	Sven Vermeulen
> 
> PS Thanks to Luis Ressel for debugging this this far.
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy