About security_path_mknod() in aufs.

John Johansen john.johansen at canonical.com
Mon Nov 15 17:02:59 UTC 2010


On 11/15/2010 06:10 AM, Tim Gardner wrote:
> On 11/09/2010 04:58 AM, Tetsuo Handa wrote:
>> Hello.
>>
>> TOMOYO has started to check 'dev' argument of security_path_mknod() since
>> 2.6.36. The argument 'dev' is passed without new_decode_dev() conversion.
>>
>> This is because I thought we should avoid useless new_decode_dev() call if
>> LSM modules (i.e. SELinux/Smack/AppArmor) don't check that argument.
>> I expected that security_path_mknod() is called from places outside vfs_mknod().
>>
>> 2016         error = security_path_mknod(&nd.path, dentry, mode, dev);
>> 2017         if (error)
>> 2018                 goto out_drop_write;
>> 2019         switch (mode&  S_IFMT) {
>> 2020                 case 0: case S_IFREG:
>> 2021                         error = vfs_create(nd.path.dentry->d_inode,dentry,mode,&nd);
>> 2022                         break;
>> 2023                 case S_IFCHR: case S_IFBLK:
>> 2024                         error = vfs_mknod(nd.path.dentry->d_inode,dentry,mode,
>> 2025                                         new_decode_dev(dev));
>>
>> But aufs's vfsub_mknod() (called from add_simple() from aufs_mknod() from
>> vfs_mknod()) is calling security_path_mknod().
>>
>>   266 int vfsub_mknod(struct inode *dir, struct path *path, int mode, dev_t dev)
>>   267 {
>>   268         int err;
>>   269         struct dentry *d;
>>   270
>>   271         IMustLock(dir);
>>   272
>>   273         d = path->dentry;
>>   274         path->dentry = d->d_parent;
>>   275         err = security_path_mknod(path, d, mode, dev);
>>   276         path->dentry = d;
>>   277         if (unlikely(err))
>>   278                 goto out;
>>   279
>>   280         err = vfs_mknod(dir, path->dentry, mode, dev);
>>
>> In vfsub_mknod(), 'dev' was already converted by 'new_decode_dev(dev)'
>> but TOMOYO is expecting 'dev' rather than 'new_decode_dev(dev)'.
>>
>> With Natty kernel, TOMOYO will check new_decode_dev(new_decode_dev(dev))
>> (which is wrong) when security_path_mknod() is called from vfsub_mknod().
>>
>> How should we fix this?
>>
>> Regards.
>>
> 
> John - any comments?
> 
Right, I got a little more from Tetsuo on this.  Basically any loop back device
doing this needs to be checked.

currently aufs is passing the wrong parameter it should be doing
-err = security_path_mknod(path, d, mode, dev);
+err = security_path_mknod(path, d, mode, new_encode_dev(dev));

long term, I think the correct solution is to patch upstream so that
security_path_mknod and vfs_mknod pass the dev argument in the same format.






More information about the kernel-team mailing list