-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello all - We just finished merging 2.6.27-rc3 into our CVS repository and there were a number of changes that affected how AppArmor interacts with the rest of the kernel. I'd like to discuss them here to determine if the delegation thread which was originally added to work with AppArmor is needed anymore. Here's the background: permission() used to take a nameidata parameter. It passed this to security_inode_permission(), which then called AppArmor. With 2.6.27, the nameidata parameter has been removed from both permission() and security_inode_permission(). Initially we wondered how AppArmor could continue to work in those circumstances. It turns out, perhaps counterintuitively, that it actually makes it _easier_ to work with AppArmor. What openSUSE 11.1 does is add a path_permission() function, a security_path_permission() function, and a security_ops->path_permission callback. All of the sites that previously had a path available (via nameidata, file, or path) still did, and so it was trivial to convert those to use the new path_permission() instead. path_permission, in turn, calls security_path_permission, which then calls the callback. LSMs that don't implement ->path_permission have the call converted automatically into ->inode_permission. Sites that don't have a path available, like may_create(), end up not calling path_permission. This is actually a good thing for AppArmor, since it used to play tricks with flags to not perform the check in those cases. The end result is that things using inode_permission don't end up getting regulated by AppArmor. Since all the old calls to inode_permission that had a path were converted to path_permission, this means that AppArmor automatically skips all the things it didn't care about before. It also means that since aufs calls inode_permission to perform it's sub-branch lookups, AppArmor isn't involved at all. This is a good thing since AppArmor is path-based and only cares about the file name that the user passed into the system call. If a confined process tries to access a component file system directly, it will be denied. If it accesses it via the aufs mount and aufs does the lookup behind the scene, it will be allowed. This is expected and appropriate behavior. SELinux, on the other hand, since it's object based, will continue to operate on component file systems as it did before. So the question is this: Since AppArmor isn't doing recursive things anymore on sub-branches, is the delegation thread needed anymore? - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkiq8EQACgkQLPWxlyuTD7JiRACaAqk+WZvJxdmI3fDXYRzHvH3U 3a8AoKUqFmt7s1zBBWTO3k0+UUextiZK =GmoK -----END PGP SIGNATURE----- ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
