Re: [Rhel6-cc-external-list] mounting cgroupfs causes directory search before sb initialization

[Eric Paris <eparis@redhat.com>]

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.