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