| |||||||||||||
Mount and symlinksMount and symlinksPosted Mar 11, 2010 11:53 UTC (Thu) by epa (subscriber, #39769)Parent article: 2.6.34 Merge window, part 2
The umount() system call supports a new UMOUNT_NOFOLLOW flag which prevents the following of symbolic links. Without this flag, local users who can perform unprivileged mounts can use a symbolic link to unmount arbitrary filesystems.Is this fixing a security hole or is it a new feature?
(Log in to post comments)
Mount and symlinks Posted Mar 11, 2010 15:15 UTC (Thu) by viro (subscriber, #7872) [Link]
That depends... If root is dumb enough to mount/umount something in user-modifiable parts of tree with users present, you are screwed anyway, symlink attacks or no symlink attacks. Just Don't Do It(tm), on any Unix.
If you are allowing non-root mounts, you need to be damn careful; it *is* possible to get it right as it is. Variant that doesn't follow symlinks makes some parts of that slightly easier; it's not a big simplification, but it makes sense and it is useful.
Whether your suid-root mount wrapper of choice is getting it right or not is a separate question, of course - all software sucks and all such.
It doesn't close any existing security holes (if nothing else, existing binaries behave as they used to) and it's not as if it was providing means for closing a hole that would be impossible to close without it.
So whether you call that fixing a security hole or not is up to you. Commit message is a bit too strong ("needed for" != "makes it easier to") and TFA is even stronger than that. The former hadn't been too far over the top and I didn't feel like editing it. As for the latter... questions to the article's author.
Here begins the countdown to wankers splashing out in force, screaming "coverup" and "conspiracy"...
Mount and symlinks Posted Mar 12, 2010 11:12 UTC (Fri) by epa (subscriber, #39769) [Link]
Ah... I didn't realize this was talking about a suid-root wrapper for mount. I misunderstood the 'users who are allowed to perform unprivileged mounts' and thought it was talking about some kernel setting to allow non-root users to call mount(2).
So what this change really does is make it more straightforward to implement a secure suid-root wrapper for mount(2) in user space.
Mount and symlinks Posted Mar 12, 2010 15:30 UTC (Fri) by nix (subscriber, #2304) [Link]
I thought that's what it was as well. I know Miklos eventually wants to be able to have random users call mount() and umount() for their own FUSE filesystems on mount points they own without relying on a setuid wrapper.
Mount and symlinks Posted Mar 12, 2010 12:19 UTC (Fri) by spender (subscriber, #23067) [Link]
coverup
conspiracy
Al, please get over yourself.
|
|||||||||||||