AVC for unlabeled_t on cgroup

AVC for unlabeled_t on cgroup

[Andy Ruch]

[-- 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 --]

Re: AVC for unlabeled_t on cgroup

[Stephen Smalley]

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.

Re: AVC for unlabeled_t on cgroup

[Andy Ruch]

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

Re: AVC for unlabeled_t on cgroup

[Stephen Smalley]

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.

Re: AVC for unlabeled_t on cgroup

[Sven Vermeulen]

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.

Re: AVC for unlabeled_t on cgroup

[Stephen Smalley]

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.