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.
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