* AVC for unlabeled_t on cgroup
@ 2013-07-11 18:38 Andy Ruch
2013-07-11 19:06 ` Stephen Smalley
2013-07-13 17:48 ` Sven Vermeulen
0 siblings, 2 replies; 6+ messages in thread
From: Andy Ruch @ 2013-07-11 18:38 UTC (permalink / raw)
To: SELinux ML
[-- Attachment #1: Type: text/plain, Size: 983 bytes --]
Hello,
I'm implementing a restrictive policy for RHEL 6.3 based on CLIP. I've enabled the cgroup module but I'm still seeing the AVC below. This is just one of a dozen similar AVC's for different inodes. When I look at the /cgroup after the system boots, everything has a cgroup_t label. Where would the unlabeled_t be coming from?
type=SYSCALL msg=audit(07/11/2013 17:25:38.885:7) : arch=x86_64 syscall=mount success=yes exit=0 a0=7f57846ac4c1 a1=7f57848b03c0 a2=7f57846ac4c1 a3=0 items=0 ppid=1177 pid=1178 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=cgconfigparser exe=/sbin/cgconfigparser subj=system_u:system_r:cgconfig_t:s0 key=(null)
type=AVC msg=audit(07/11/2013 17:25:38.885:7) : avc: denied { search } for pid=1178 comm=cgconfigparser name=/ dev=cgroup ino=12518 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir
Thanks,
Andrew Ruch
[-- Attachment #2: Type: text/html, Size: 1894 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: AVC for unlabeled_t on cgroup
2013-07-11 18:38 AVC for unlabeled_t on cgroup Andy Ruch
@ 2013-07-11 19:06 ` Stephen Smalley
2013-07-11 19:24 ` Andy Ruch
2013-07-13 17:48 ` Sven Vermeulen
1 sibling, 1 reply; 6+ messages in thread
From: Stephen Smalley @ 2013-07-11 19:06 UTC (permalink / raw)
To: Andy Ruch; +Cc: SELinux ML
On 07/11/2013 02:38 PM, Andy Ruch wrote:
> Hello,
>
> I'm implementing a restrictive policy for RHEL 6.3 based on CLIP. I've enabled the cgroup module but I'm still seeing the AVC below. This is just one of a dozen similar AVC's for different inodes. When I look at the /cgroup after the system boots, everything has a cgroup_t label. Where would the unlabeled_t be coming from?
>
>
>
> type=SYSCALL msg=audit(07/11/2013 17:25:38.885:7) : arch=x86_64 syscall=mount success=yes exit=0 a0=7f57846ac4c1 a1=7f57848b03c0 a2=7f57846ac4c1 a3=0 items=0 ppid=1177 pid=1178 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=cgconfigparser exe=/sbin/cgconfigparser subj=system_u:system_r:cgconfig_t:s0 key=(null)
>
> type=AVC msg=audit(07/11/2013 17:25:38.885:7) : avc: denied { search } for pid=1178 comm=cgconfigparser name=/ dev=cgroup ino=12518 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir
That's likely a kernel-internal lookup during creation of a cgroup
inode. cgroup has some code to switch to the kernel credential when
performing such lookups to avoid permission denials IIRC, which presumes
then that you allow this in your policy. Doesn't show up in typical
policies as they allow kernel_t all access since it can do anything it
wants anyway.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: AVC for unlabeled_t on cgroup
2013-07-11 19:06 ` Stephen Smalley
@ 2013-07-11 19:24 ` Andy Ruch
2013-07-11 19:38 ` Stephen Smalley
0 siblings, 1 reply; 6+ messages in thread
From: Andy Ruch @ 2013-07-11 19:24 UTC (permalink / raw)
To: Stephen Smalley; +Cc: SELinux ML
>________________________________
> From: Stephen Smalley <sds@tycho.nsa.gov>
>To: Andy Ruch <adruch2002@yahoo.com>
>Cc: SELinux ML <selinux@tycho.nsa.gov>
>Sent: Thursday, July 11, 2013 1:06 PM
>Subject: Re: AVC for unlabeled_t on cgroup
>
>
>On 07/11/2013 02:38 PM, Andy Ruch wrote:
>> Hello,
>>
>> I'm implementing a restrictive policy for RHEL 6.3 based on CLIP. I've enabled the cgroup module but I'm still seeing the AVC below. This is just one of a dozen similar AVC's for different inodes. When I look at the /cgroup after the system boots, everything has a cgroup_t label. Where would the unlabeled_t be coming from?
>>
>>
>>
>> type=SYSCALL msg=audit(07/11/2013 17:25:38.885:7) : arch=x86_64 syscall=mount success=yes exit=0 a0=7f57846ac4c1 a1=7f57848b03c0 a2=7f57846ac4c1 a3=0 items=0 ppid=1177 pid=1178 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=cgconfigparser exe=/sbin/cgconfigparser subj=system_u:system_r:cgconfig_t:s0 key=(null)
>>
>> type=AVC msg=audit(07/11/2013 17:25:38.885:7) : avc: denied { search } for pid=1178 comm=cgconfigparser name=/ dev=cgroup ino=12518 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir
>
>That's likely a kernel-internal lookup during creation of a cgroup
>inode. cgroup has some code to switch to the kernel credential when
>performing such lookups to avoid permission denials IIRC, which presumes
>then that you allow this in your policy. Doesn't show up in typical
>policies as they allow kernel_t all access since it can do anything it
>wants anyway.
>
>
>
Since this is beyond my expertise, any recommendations for handling it? Do I ignore it? Allowing kernel_t all access doesn't seem like a good option for a secure system. We're not really using cgroups, but it's required for libvirt.
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: AVC for unlabeled_t on cgroup
2013-07-11 19:24 ` Andy Ruch
@ 2013-07-11 19:38 ` Stephen Smalley
0 siblings, 0 replies; 6+ messages in thread
From: Stephen Smalley @ 2013-07-11 19:38 UTC (permalink / raw)
To: Andy Ruch; +Cc: SELinux ML
On 07/11/2013 03:24 PM, Andy Ruch wrote:
>
>> ________________________________
>> From: Stephen Smalley <sds@tycho.nsa.gov>
>> To: Andy Ruch <adruch2002@yahoo.com>
>> Cc: SELinux ML <selinux@tycho.nsa.gov>
>> Sent: Thursday, July 11, 2013 1:06 PM
>> Subject: Re: AVC for unlabeled_t on cgroup
>>
>>
>> On 07/11/2013 02:38 PM, Andy Ruch wrote:
>>> Hello,
>>>
>>> I'm implementing a restrictive policy for RHEL 6.3 based on CLIP. I've enabled the cgroup module but I'm still seeing the AVC below. This is just one of a dozen similar AVC's for different inodes. When I look at the /cgroup after the system boots, everything has a cgroup_t label. Where would the unlabeled_t be coming from?
>>>
>>>
>>>
>>> type=SYSCALL msg=audit(07/11/2013 17:25:38.885:7) : arch=x86_64 syscall=mount success=yes exit=0 a0=7f57846ac4c1 a1=7f57848b03c0 a2=7f57846ac4c1 a3=0 items=0 ppid=1177 pid=1178 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=cgconfigparser exe=/sbin/cgconfigparser subj=system_u:system_r:cgconfig_t:s0 key=(null)
>>>
>>> type=AVC msg=audit(07/11/2013 17:25:38.885:7) : avc: denied { search } for pid=1178 comm=cgconfigparser name=/ dev=cgroup ino=12518 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir
>>
>> That's likely a kernel-internal lookup during creation of a cgroup
>> inode. cgroup has some code to switch to the kernel credential when
>> performing such lookups to avoid permission denials IIRC, which presumes
>> then that you allow this in your policy. Doesn't show up in typical
>> policies as they allow kernel_t all access since it can do anything it
>> wants anyway.
>>
>>
>>
>
>
> Since this is beyond my expertise, any recommendations for handling it? Do I ignore it? Allowing kernel_t all access doesn't seem like a good option for a secure system. We're not really using cgroups, but it's required for libvirt.
I would allow it. The kernel can do anything it wants regardless, so
you don't gain any security by denying it, and denying it will likely
break cgroup usage. The only thing to make sure of is that nothing is
running in kernel_t other than kernel threads, e.g.
$ ps -elZ | grep kernel_t | awk '$6 != 2 {print}'
system_u:system_r:kernel_t:s0 1 S 0 2 0 0 80 0 - 0
kthrea ? 00:00:00 kthreadd
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: AVC for unlabeled_t on cgroup
2013-07-11 18:38 AVC for unlabeled_t on cgroup Andy Ruch
2013-07-11 19:06 ` Stephen Smalley
@ 2013-07-13 17:48 ` Sven Vermeulen
2013-07-15 13:07 ` Stephen Smalley
1 sibling, 1 reply; 6+ messages in thread
From: Sven Vermeulen @ 2013-07-13 17:48 UTC (permalink / raw)
To: Andy Ruch; +Cc: SELinux ML
On Thu, Jul 11, 2013 at 11:38:57AM -0700, Andy Ruch wrote:
> I'm implementing a restrictive policy for RHEL 6.3 based on CLIP. I've enabled the cgroup module but I'm still seeing the AVC below. This is just one of a dozen similar AVC's for different inodes. When I look at the /cgroup after the system boots, everything has a cgroup_t label. Where would the unlabeled_t be coming from?
>
>
>
> type=SYSCALL msg=audit(07/11/2013 17:25:38.885:7) : arch=x86_64 syscall=mount success=yes exit=0 a0=7f57846ac4c1 a1=7f57848b03c0 a2=7f57846ac4c1 a3=0 items=0 ppid=1177 pid=1178 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=cgconfigparser exe=/sbin/cgconfigparser subj=system_u:system_r:cgconfig_t:s0 key=(null)
>
> type=AVC msg=audit(07/11/2013 17:25:38.885:7) : avc: denied { search } for pid=1178 comm=cgconfigparser name=/ dev=cgroup ino=12518 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir
The cgroup_t label might be put on it afterwards (check your udev rules and
scripts to see if they don't relabel files), but my guess is that the
directory is marked as unlabeled_t and that cgroup file system is mounted on
top of it later. Once it is mounted, you see the context of the files (and
directories) in the mounted file system, which is cgroup_t.
Try bindmounting root elsewhere and see what the label is of the directory.
Also, the process cgconfigparser is running as kernel_t, which we probably
don't want. The kernel is probably configured to trigger that script
somewhere (or through another script) and because there is no transition
defined, the script remains running as kernel_t.
For instance, in Gentoo, we have a script that is called after the last task
is removed from a control group; we mark that script as a specific exec
script (openrc_cgroup_release_exec_t here) and have a transition from
kernel_t to openrc_cgroup_release_t upon execution.
This is through cgroup's notify_on_release implementation (release agent).
Perhaps the cgconfigparser is also executed through a cgroup feature by the
kernel?
Wkr,
Sven Vermeulen
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: AVC for unlabeled_t on cgroup
2013-07-13 17:48 ` Sven Vermeulen
@ 2013-07-15 13:07 ` Stephen Smalley
0 siblings, 0 replies; 6+ messages in thread
From: Stephen Smalley @ 2013-07-15 13:07 UTC (permalink / raw)
To: Sven Vermeulen; +Cc: Andy Ruch, SELinux ML, Eric Paris
On 07/13/2013 01:48 PM, Sven Vermeulen wrote:
> On Thu, Jul 11, 2013 at 11:38:57AM -0700, Andy Ruch wrote:
>> I'm implementing a restrictive policy for RHEL 6.3 based on CLIP. I've enabled the cgroup module but I'm still seeing the AVC below. This is just one of a dozen similar AVC's for different inodes. When I look at the /cgroup after the system boots, everything has a cgroup_t label. Where would the unlabeled_t be coming from?
>>
>>
>>
>> type=SYSCALL msg=audit(07/11/2013 17:25:38.885:7) : arch=x86_64 syscall=mount success=yes exit=0 a0=7f57846ac4c1 a1=7f57848b03c0 a2=7f57846ac4c1 a3=0 items=0 ppid=1177 pid=1178 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=cgconfigparser exe=/sbin/cgconfigparser subj=system_u:system_r:cgconfig_t:s0 key=(null)
>>
>> type=AVC msg=audit(07/11/2013 17:25:38.885:7) : avc: denied { search } for pid=1178 comm=cgconfigparser name=/ dev=cgroup ino=12518 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir
>
> The cgroup_t label might be put on it afterwards (check your udev rules and
> scripts to see if they don't relabel files), but my guess is that the
> directory is marked as unlabeled_t and that cgroup file system is mounted on
> top of it later. Once it is mounted, you see the context of the files (and
> directories) in the mounted file system, which is cgroup_t.
>
> Try bindmounting root elsewhere and see what the label is of the directory.
>
> Also, the process cgconfigparser is running as kernel_t, which we probably
> don't want. The kernel is probably configured to trigger that script
> somewhere (or through another script) and because there is no transition
> defined, the script remains running as kernel_t.
>
> For instance, in Gentoo, we have a script that is called after the last task
> is removed from a control group; we mark that script as a specific exec
> script (openrc_cgroup_release_exec_t here) and have a transition from
> kernel_t to openrc_cgroup_release_t upon execution.
>
> This is through cgroup's notify_on_release implementation (release agent).
> Perhaps the cgconfigparser is also executed through a cgroup feature by the
> kernel?
No, it is an internal credential switch by the kernel when populating
the cgroup directory. See:
commit 2ce9738bac1b386f46e8478fd2c263460e7c2b09
Author: eparis@redhat <eparis@redhat>
Date: Thu Jun 2 21:20:51 2011 +1000
cgroupfs: use init_cred when populating new cgroupfs mount
We recently found that in some configurations SELinux was blocking
the abili
for cgroupfs to be mounted. The reason for this is because
cgroupfs creates
files and directories during the get_sb() call and also uses
lookup_one_len(
during that same get_sb() call. This is a problem since the security
subsystem cannot initialize the superblock and the inodes in that
filesystem
until after the get_sb() call returns. Thus we leave the inodes in
an unitialized state during get_sb(). For the vast majority of
filesystems
this is not an issue, but since cgroupfs uses lookup_on_len() it does
search permission checks on the directories in the path it walks.
Since the
inode security state is not set up SELinux does these checks as if
the inode
were 'unlabeled.'
Many 'normal' userspace process do not have permission to interact with
unlabeled inodes. The solution presented here is to do the
permission check
of path walk and inode creation as the kernel rather than as the
task that
called mount. Since the kernel has permission to read/write/create
unlabeled inodes the get_sb() call will complete successfully and
the SELinu
code will be able to initialize the superblock and those inodes
created duri
the get_sb() call.
This appears to be the same solution used by other filesystems such
as devtm
to solve the same issue and should thus have no negative impact on
other LSM
which currently work.
Signed-off-by: Eric Paris <eparis@redhat.com>
Acked-by: Paul Menage <menage@google.com>
Signed-off-by: James Morris <jmorris@namei.org>
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-07-15 13:07 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-07-11 18:38 AVC for unlabeled_t on cgroup Andy Ruch
2013-07-11 19:06 ` Stephen Smalley
2013-07-11 19:24 ` Andy Ruch
2013-07-11 19:38 ` Stephen Smalley
2013-07-13 17:48 ` Sven Vermeulen
2013-07-15 13:07 ` Stephen Smalley
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.