* [refpolicy] RFC: kernel_t exec rights on cgroup_t files
@ 2013-02-12 19:47 Sven Vermeulen
2013-02-12 20:00 ` Dominick Grift
0 siblings, 1 reply; 10+ messages in thread
From: Sven Vermeulen @ 2013-02-12 19:47 UTC (permalink / raw)
To: refpolicy
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.
^ permalink raw reply [flat|nested] 10+ messages in thread* [refpolicy] RFC: kernel_t exec rights on cgroup_t files
2013-02-12 19:47 [refpolicy] RFC: kernel_t exec rights on cgroup_t files Sven Vermeulen
@ 2013-02-12 20:00 ` Dominick Grift
0 siblings, 0 replies; 10+ messages in thread
From: Dominick Grift @ 2013-02-12 20:00 UTC (permalink / raw)
To: refpolicy
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [refpolicy] RFC: kernel_t exec rights on cgroup_t files
@ 2013-02-12 20:31 aranea at aixah.de
2013-02-12 20:34 ` Dominick Grift
0 siblings, 1 reply; 10+ messages in thread
From: aranea at aixah.de @ 2013-02-12 20:31 UTC (permalink / raw)
To: refpolicy
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [refpolicy] RFC: kernel_t exec rights on cgroup_t files
2013-02-12 20:31 aranea at aixah.de
@ 2013-02-12 20:34 ` Dominick Grift
2013-02-12 20:47 ` aranea at aixah.de
0 siblings, 1 reply; 10+ messages in thread
From: Dominick Grift @ 2013-02-12 20:34 UTC (permalink / raw)
To: refpolicy
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [refpolicy] RFC: kernel_t exec rights on cgroup_t files
2013-02-12 20:34 ` Dominick Grift
@ 2013-02-12 20:47 ` aranea at aixah.de
2013-02-12 21:12 ` Dominick Grift
0 siblings, 1 reply; 10+ messages in thread
From: aranea at aixah.de @ 2013-02-12 20:47 UTC (permalink / raw)
To: refpolicy
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
^ permalink raw reply [flat|nested] 10+ messages in thread* [refpolicy] RFC: kernel_t exec rights on cgroup_t files
2013-02-12 20:47 ` aranea at aixah.de
@ 2013-02-12 21:12 ` Dominick Grift
2013-02-12 21:25 ` aranea at aixah.de
0 siblings, 1 reply; 10+ messages in thread
From: Dominick Grift @ 2013-02-12 21:12 UTC (permalink / raw)
To: refpolicy
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [refpolicy] RFC: kernel_t exec rights on cgroup_t files
2013-02-12 21:12 ` Dominick Grift
@ 2013-02-12 21:25 ` aranea at aixah.de
2013-02-12 21:32 ` aranea at aixah.de
0 siblings, 1 reply; 10+ messages in thread
From: aranea at aixah.de @ 2013-02-12 21:25 UTC (permalink / raw)
To: refpolicy
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [refpolicy] RFC: kernel_t exec rights on cgroup_t files
2013-02-12 21:25 ` aranea at aixah.de
@ 2013-02-12 21:32 ` aranea at aixah.de
2013-02-12 21:51 ` aranea at aixah.de
0 siblings, 1 reply; 10+ messages in thread
From: aranea at aixah.de @ 2013-02-12 21:32 UTC (permalink / raw)
To: refpolicy
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [refpolicy] RFC: kernel_t exec rights on cgroup_t files
2013-02-12 21:32 ` aranea at aixah.de
@ 2013-02-12 21:51 ` aranea at aixah.de
2013-02-15 21:12 ` Luis Ressel
0 siblings, 1 reply; 10+ messages in thread
From: aranea at aixah.de @ 2013-02-12 21:51 UTC (permalink / raw)
To: refpolicy
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
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-02-15 21:12 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-02-12 19:47 [refpolicy] RFC: kernel_t exec rights on cgroup_t files Sven Vermeulen
2013-02-12 20:00 ` Dominick Grift
-- strict thread matches above, loose matches on Subject: below --
2013-02-12 20:31 aranea at aixah.de
2013-02-12 20:34 ` Dominick Grift
2013-02-12 20:47 ` aranea at aixah.de
2013-02-12 21:12 ` Dominick Grift
2013-02-12 21:25 ` aranea at aixah.de
2013-02-12 21:32 ` aranea at aixah.de
2013-02-12 21:51 ` aranea at aixah.de
2013-02-15 21:12 ` Luis Ressel
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.