mounting cgroupfs causes directory search before sb initialization

mounting cgroupfs causes directory search before sb initialization

[Eric Paris]

Running the RHEL6 MLS policy we find that we have trouble mounting
cgroupfs with denials that look like so:

time->Wed May 25 13:24:28 2011
type=PATH msg=audit(1306347868.791:11): item=0 name="/cgroup/freezer" inode=24658 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:cgroup_t:s0
type=CWD msg=audit(1306347868.791:11):  cwd="/"
type=SYSCALL msg=audit(1306347868.791:11): arch=c000003e syscall=165 success=yes exit=0 a0=7f9561cb0481 a1=7f9561ebe414 a2=7f9561cb0481 a3=0 items=1 ppid=944 pid=945 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="cgconfigparser" exe="/sbin/cgconfigparser" subj=system_u:system_r:cgconfig_t:s0-s15:c0.c1023 key=(null)
type=AVC msg=audit(1306347868.791:11): avc:  denied  { search } for  pid=945 comm="cgconfigparser" name="/" dev=cgroup ino=9436 scontext=system_u:system_r:cgconfig_t:s0-s15:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s15:c0.c1023 tclass=dir

After quite a bit of code inspection I think I understand the problem (although not completely). I believe the problem is that during the get_sb() call cgroupfs creates not only the root directory inode but also creates files inside that directory.  During that creation of other files (like in this case "freezer") the code does:

vfs_kern_mount()
  cgroup_get_sb()
    cgroup_populate_dir()
      cgroup_add_files()
        lookup_one_len()
        alloc_dentry()
        d_instantiate()

It seems to use lookup_one_len() to make sure it isn't adding 
the same file twice.  Now the problem is that since we are still 
inside get_sb() we haven't made it to security_sb_kern_mount() 
which actually initializes the superblock security struct (and the 
root inode).  Thus sbsec->flags & SE_SBINITIALIZED isn't set, so 
the root inode will not have been initialized.  Now when 
lookup_on_len() tries to search the new root inode it's going to 
get SECINITSID_UNLABELED.

I honestly am not sure how to fix it.  I could mark the root inode 
PRIVATE while get_sb() was taking place, but that wouldn't work if 
they ever started creating directory structures during mount.  
Maybe we can somehow force the cgroup people to do the creation of 
the files inside cgroupfs root inode after the sb is initialized?  
I'm just not sure how to solve it.  Any ideas?

-Eric

--
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: mounting cgroupfs causes directory search before sb initialization

[Stephen Smalley]

On Wed, 2011-05-25 at 15:43 -0400, Eric Paris wrote:
> Running the RHEL6 MLS policy we find that we have trouble mounting
> cgroupfs with denials that look like so:
> 
> time->Wed May 25 13:24:28 2011
> type=PATH msg=audit(1306347868.791:11): item=0 name="/cgroup/freezer" inode=24658 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:cgroup_t:s0
> type=CWD msg=audit(1306347868.791:11):  cwd="/"
> type=SYSCALL msg=audit(1306347868.791:11): arch=c000003e syscall=165 success=yes exit=0 a0=7f9561cb0481 a1=7f9561ebe414 a2=7f9561cb0481 a3=0 items=1 ppid=944 pid=945 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="cgconfigparser" exe="/sbin/cgconfigparser" subj=system_u:system_r:cgconfig_t:s0-s15:c0.c1023 key=(null)
> type=AVC msg=audit(1306347868.791:11): avc:  denied  { search } for  pid=945 comm="cgconfigparser" name="/" dev=cgroup ino=9436 scontext=system_u:system_r:cgconfig_t:s0-s15:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s15:c0.c1023 tclass=dir
> 
> After quite a bit of code inspection I think I understand the problem (although not completely). I believe the problem is that during the get_sb() call cgroupfs creates not only the root directory inode but also creates files inside that directory.  During that creation of other files (like in this case "freezer") the code does:
> 
> vfs_kern_mount()
>   cgroup_get_sb()
>     cgroup_populate_dir()
>       cgroup_add_files()
>         lookup_one_len()
>         alloc_dentry()
>         d_instantiate()
> 
> It seems to use lookup_one_len() to make sure it isn't adding 
> the same file twice.  Now the problem is that since we are still 
> inside get_sb() we haven't made it to security_sb_kern_mount() 
> which actually initializes the superblock security struct (and the 
> root inode).  Thus sbsec->flags & SE_SBINITIALIZED isn't set, so 
> the root inode will not have been initialized.  Now when 
> lookup_on_len() tries to search the new root inode it's going to 
> get SECINITSID_UNLABELED.
> 
> I honestly am not sure how to fix it.  I could mark the root inode 
> PRIVATE while get_sb() was taking place, but that wouldn't work if 
> they ever started creating directory structures during mount.  
> Maybe we can somehow force the cgroup people to do the creation of 
> the files inside cgroupfs root inode after the sb is initialized?  
> I'm just not sure how to solve it.  Any ideas?

You could do what devtmpfs does, e.g.
cred = override_creds(&init_cred);
<perform internal fs operations>
revert_creds(cred);

-- 
Stephen Smalley
National Security Agency


--
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: [Rhel6-cc-external-list] mounting cgroupfs causes directory search before sb initialization

[Eric Paris]

On 05/25/2011 04:21 PM, Stephan Mueller wrote:
> Am Mittwoch, 25. Mai 2011, um 21:43:44 schrieb Eric Paris:
> 
> Hi Eric,
> 
>> Running the RHEL6 MLS policy we find that we have trouble mounting
>> cgroupfs with denials that look like so:
>>
>> time->Wed May 25 13:24:28 2011
>> type=PATH msg=audit(1306347868.791:11): item=0 name="/cgroup/freezer"
>> inode=24658 dev=fd:00 mode=040755 ouid=0 ogid=0 rdev=00:00
>> obj=system_u:object_r:cgroup_t:s0 type=CWD msg=audit(1306347868.791:11): 
>> cwd="/"
>> type=SYSCALL msg=audit(1306347868.791:11): arch=c000003e syscall=165
>> success=yes exit=0 a0=7f9561cb0481 a1=7f9561ebe414 a2=7f9561cb0481 a3=0
>> items=1 ppid=944 pid=945 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0
>> egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="cgconfigparser"
>> exe="/sbin/cgconfigparser"
>> subj=system_u:system_r:cgconfig_t:s0-s15:c0.c1023 key=(null) type=AVC
>> msg=audit(1306347868.791:11): avc:  denied  { search } for  pid=945
>> comm="cgconfigparser" name="/" dev=cgroup ino=9436
>> scontext=system_u:system_r:cgconfig_t:s0-s15:c0.c1023
>> tcontext=system_u:object_r:unlabeled_t:s15:c0.c1023 tclass=dir
>>
>> After quite a bit of code inspection I think I understand the problem
>> (although not completely). I believe the problem is that during the
>> get_sb() call cgroupfs creates not only the root directory inode but also
>> creates files inside that directory.  During that creation of other files
>> (like in this case "freezer") the code does:
>>
>> vfs_kern_mount()
>>   cgroup_get_sb()
>>     cgroup_populate_dir()
>>       cgroup_add_files()
>>         lookup_one_len()
>>         alloc_dentry()
>>         d_instantiate()
>>
>> It seems to use lookup_one_len() to make sure it isn't adding
>> the same file twice.  Now the problem is that since we are still
>> inside get_sb() we haven't made it to security_sb_kern_mount()
>> which actually initializes the superblock security struct (and the
>> root inode).  Thus sbsec->flags & SE_SBINITIALIZED isn't set, so
>> the root inode will not have been initialized.  Now when
>> lookup_on_len() tries to search the new root inode it's going to
>> get SECINITSID_UNLABELED.
>>
>> I honestly am not sure how to fix it.  I could mark the root inode
>> PRIVATE while get_sb() was taking place, but that wouldn't work if
>> they ever started creating directory structures during mount.
>> Maybe we can somehow force the cgroup people to do the creation of
>> the files inside cgroupfs root inode after the sb is initialized?
>> I'm just not sure how to solve it.  Any ideas?
> 
> What about simply adding a call to security_sb_kern_mount to the cgroup_get_sb 
> function immediately before
> 
> 	if (root == opts.new_root) {
> 
> ?
> 
> Is there any harm when this function is called twice?

No, but we don't pass the security mount options (like context=) down to
get_sb() and we need those in sb_kern_mount  :(

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