Christoph Hellwig wrote: > On Thu, Nov 08, 2007 at 07:04:23AM +0900, Tetsuo Handa wrote: >> The reason why I want to access namespace_sem inside security_inode_create() is that >> it doesn't receive "struct vfsmount" parameter. >> If "struct vfsmount" *were* passed to security_inode_create(), >> I have no need to access namespace_sem. >> > Same argument as with the AA folks: it does not have any business looking > at the vfsmount. If you create a file it can and in many setups will > show up in multiple vfsmounts, so making decisions based on the particular > one this creat happens through is wrong and actually dangerous. > This has been said many times, and I have never been able to translate it into anything other than "pathname access control is bad". Pathname-based access control systems, among other things, let you write a policy that says "you may create files under /foo/bar/baz". So when you attempt to create a file "/foo/bar/baz/biff" the LSM needs to know which VFS mount you are creating it in. Multiple mount points, bind mounts, and other fun with mounting, do in fact allow you to create aliases. Because of that, an LSM that set a policy of "you can create files anywhere *except* /foo/bar/baz" would be trivially bypassable. But a policy that says "You may *only* create files under /foo/bar/baz" (plus whatever other explicit permissions it grants) does not seem to create any problems, so long as the confined processes are not permitted to create arbitrary aliases by using fun with mount. So just exactly what is dangerous about this? Caveat: complaints that you can create a policy that is bypassable are not interesting, you can do that with any policy system. To show "dangerous" you would have to show how a reasonable policy that should be secure is in fact bypassable. This threat from mount point aliases, this has often been conjectured but has never been shown. Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin CEO, Mercenary Linux http://mercenarylinux.com/ Itanium. Vista. GPLv3. Complexity at work - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
