[refpolicy] RFC: kernel_t exec rights on cgroup_t files

[refpolicy] RFC: kernel_t exec rights on cgroup_t files

[Sven Vermeulen]

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.

[refpolicy] RFC: kernel_t exec rights on cgroup_t files

[Dominick Grift]

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

[refpolicy] RFC: kernel_t exec rights on cgroup_t files

[aranea at aixah.de]

Hi, I made a mistake while debugging.


allow kernel_t cgroup_t:file exec_file_perms;
allow kernel_t cgroup_t:dir list_dir_perms;

(which I originally tried) doesn't solve the problem, and neither does
the proposed

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


Regards,
Luis Ressel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20130212/fdc465a5/attachment.bin 

[refpolicy] RFC: kernel_t exec rights on cgroup_t files

[Dominick Grift]

On Tue, 2013-02-12 at 21:31 +0100, aranea at aixah.de wrote:
> Hi, I made a mistake while debugging.
> 
> 
> allow kernel_t cgroup_t:file exec_file_perms;
> allow kernel_t cgroup_t:dir list_dir_perms;
> 
> (which I originally tried) doesn't solve the problem, and neither does
> the proposed
> 

So what does solve the problem and what AVC denials are you seeing? (can
you enclose the AVC denials?)

> dontaudit kernel_t cgroup_t:file execute;
> allow kernel_t cgroup_t:file audit_access;
> 
> 
> Regards,
> Luis Ressel
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

[refpolicy] RFC: kernel_t exec rights on cgroup_t files

[aranea at aixah.de]

On Tue, 12 Feb 2013 21:34:59 +0100
Dominick Grift <dominick.grift@gmail.com> wrote:

> On Tue, 2013-02-12 at 21:31 +0100, aranea at aixah.de wrote:
> > Hi, I made a mistake while debugging.
> > 
> > 
> > allow kernel_t cgroup_t:file exec_file_perms;
> > allow kernel_t cgroup_t:dir list_dir_perms;
> > 
> > (which I originally tried) doesn't solve the problem, and neither
> > does the proposed
> > 
> 
> So what does solve the problem and what AVC denials are you seeing?
> (can you enclose the AVC denials?)
> 
I haven't solved the problem until now. The errors which the OP
mentioned appear in a early boot phase, most probably while executing
this script:

        local agent="/lib64/rc/sh/cgroup-release-agent.sh"
        mkdir /sys/fs/cgroup/openrc
        mount -n -t cgroup \
                -o none,nodev,noexec,nosuid,name=openrc,release_agent="$agent" \
		openrc /sys/fs/cgroup/openrc echo 1 > /sys/fs/cgroup/openrc/notify_on_release


The problem is that there are no denial messages, even if I disable the dontaudit rules.
But I'm absolutely sure SELinux is causing the problem, as everything works in permissive mode.


Regards, Luis Ressel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20130212/d94af650/attachment.bin 

[refpolicy] RFC: kernel_t exec rights on cgroup_t files

[Dominick Grift]

On Tue, 2013-02-12 at 21:47 +0100, aranea at aixah.de wrote:
> 
> The problem is that there are no denial messages, even if I disable the dontaudit rules.
> But I'm absolutely sure SELinux is causing the problem, as everything works in permissive mode.
> 

Did you also look for them in dmesg? But yes with these early boot
things logging may be an issue.

Kind of hard to troubleshoot without any AVC denials

Is that script in initramfs? Maybe there is a way for whatever runs it
to be more verbose.

> 
> Regards, Luis Ressel
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

[refpolicy] RFC: kernel_t exec rights on cgroup_t files

[aranea at aixah.de]

On Tue, 12 Feb 2013 22:12:54 +0100
Dominick Grift <dominick.grift@gmail.com> wrote:

> On Tue, 2013-02-12 at 21:47 +0100, aranea at aixah.de wrote:
> > 
> > The problem is that there are no denial messages, even if I disable
> > the dontaudit rules. But I'm absolutely sure SELinux is causing the
> > problem, as everything works in permissive mode.
> > 
> 
> Did you also look for them in dmesg? But yes with these early boot
> things logging may be an issue.
> 
> Kind of hard to troubleshoot without any AVC denials
> 
> Is that script in initramfs? Maybe there is a way for whatever runs it
> to be more verbose.

No, it isn't in an initramfs. It's part of OpenRC (Gentoo Linux'
default init system) and is located on the root partition.

Also I know logging theoretically works at the point it runs, as the
first logged avc denials (dontaudit ones) start 5 secs after booting
and these errors occur at 7 secs.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20130212/084dc84c/attachment.bin 

[refpolicy] RFC: kernel_t exec rights on cgroup_t files

[aranea at aixah.de]

Here's another interesting thing: The file in question
(/sys/fs/cgroup/openrc/notify_on_release) does not even exist!
In fact, this directory doesn't include any files (but some
directories) when booting in enforcing mode.

In permissive mode however, there are some files
(cgroup.clone_children, cgroup.event_control, cgroup.procs,
notify_on_release, release_agent, tasks) there.

This could mean that the error messages at 7 secs are only reactions to
something which happens even earlier, when there's really no logging
taking place.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20130212/6f638489/attachment.bin 

[refpolicy] RFC: kernel_t exec rights on cgroup_t files

[aranea at aixah.de]

On Tue, 12 Feb 2013 22:32:07 +0100
<aranea@aixah.de> wrote:

> Here's another interesting thing: The file in question
> (/sys/fs/cgroup/openrc/notify_on_release) does not even exist!
> In fact, this directory doesn't include any files (but some
> directories) when booting in enforcing mode.
> 
> In permissive mode however, there are some files
> (cgroup.clone_children, cgroup.event_control, cgroup.procs,
> notify_on_release, release_agent, tasks) there.
> 
> This could mean that the error messages at 7 secs are only reactions
> to something which happens even earlier, when there's really no
> logging taking place.

Sorry, looks like I had one of these attacks of extreme dumbness you
sometimes have when the uptime is > 10h. Clearly these files don't
exist, as that's exactly what the error messages are complaining
about: It was for some reason not possible to create them.

I'll continue to debug this tommorow.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20130212/d30ff030/attachment-0001.bin 

[refpolicy] RFC: kernel_t exec rights on cgroup_t files

[Luis Ressel]

The problem has been solved; See
https://bugs.gentoo.org/show_bug.cgi?id=457618 for details.

Luis Ressel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20130215/9d5ca9bc/attachment.bin