On Mon, Dec 7, 2009 at 9:13 AM, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote: >> > That is *exactly* the problem, which is clearly what you are missing here. >> >> I don't think so, but maybe I'm wrong. Could you describe your attack >> scenario in detail then, please? > > First obvious attack: get an O_NODE handle to a device you have assigned > to your ownership > > while(1) > fchmod(fd, 0666); > > wait for device to unload, reload and be intended for another user > Race udev to a real open. You have a similar problem with vhangup() and > ttys. Huh? I would've thought that udev would (and already does?), on device unload, chown to 0:0, then chmod to 0000, then unlink, in which case that attack doesn't work. If you mean that someone could have an O_NODE handle open, then the device unregisters, then, before udev has a chance to do anything at all, a new device w/ the same major/minor numbers appears, then the O_NODE handle owner upgrades to a real fd, then we have worse worries: the attacker could just open the device node on disk without O_NODE, hard links, or any other funny tricks. revoke() wouldn't fix that either. I'll admit that O_NODE scares me a bit from a security perspective, but so do hard links and /proc/self/fd in general, and I'm not really convinced that there are any new attacks here. Would you be okay with a patch that prevented opening /proc/self/fd/xxx on O_NODE handles? I personally don't care about O_NODE all that much, but I'd like a decent in-kernel AFS implementation (and a decent revoke() implementation, and especially the ability to revoke whole filesystems would be really nice too). --Andy > > This cannot happen with the existing kernel because there cannot be an > open handle when the original device unload occurs[1] and it cannot happen > with vhangup because the hangup is basically a special case revoke() > implementation for tty devices. > > O_NODE changes the whole lifetime semantics for inodes. It's not > something you can do casually. pioctl() gets this right although for the > same reason as path based chmod/chown/etc all get it right, O_NODE breaks > it all horribly. > > Alan > [1] If you think about it a wait for no references is the same barrier as > a revoke but a blocking one. > -- 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
