On Fri, Oct 23, 2009 at 11:57:58PM +0400, Dan Yefimov wrote: > That can hardly be called a real security hole, since the behaviour > described above is expected, and is as it was conceived by design. Lots of security holes can fall into that category! The code matches its design, and works as expected... it's just that the author had no idea what he was getting himself into. =8^) > If the file owner in fact allows writing to it, why should Linux > prevent that from happening? Because securing a file by securing directories that lead to it is a valid and important (and expected) feature of file access semantics. That said, the user in the example already has access to the file (in a running process), and would be able to do so again, *if he had access to a directory where the file was hard-linked*. Pavel described that the sysadmin checked for that, but even if this worked as expected, there's a race condition where the user could create the hard link after the sysadmin checked, but before the permissions were corrected. Unlikely, I know... but possible. There's a nearly identical case that works in all Unixen, AFAIK: You have /a/b/file1, which is writable to user1. The user has permission to descend /a and /a/b. At some point user1 does a cd to /a/b. Then at some later point, while the user still has that shell open, the sysadmin closes off permission to /a, and user1 no longer can descend it. But it doesn't matter... user1 has already got a shell open in /a/b, and therefore full access to all the files there which are not otherwise protected against that user's access. user1 can copy them, mail them to friends, make hard links to them, etc.... Anything desired, until that shell is closed. This case won't work if you close off /a/b, because you need to be able to modify the directory in order to write to the file (I'm getting to that)... I don't think what Pavel described is a very serious hole, but it *IS* a hole, because: 1. It circumvents the fact that to write to a file, you MUST be able to write to its directory, so that the file attributes can be updated. That's an important part of accountability. 2. One of two things must be true: either the real directory itself is not updated when the file is written (likely), or the directory IS modified when the file is written, despite the fact that the user does not have access to update the directory. Either way, BAD LINUX. I think there is one other legitimate answer to your question above: If the person who created/accessed the file is an unauthorized user, and the person who closed off directory access was responding to the intrusion. This includes a user who is authorized to use the system, but has gained access to some part of the system that should not be accessible, either by accident or by willful misdeed. Of course, there are likely other, better ways to respond than to simply close off the directory permissions... but someone who is not expert in this aspect of the behavior of the Linux kernel has every reason to think that doing that would work. It's not documented anywhere a typical sysadmin is likely to look that this method of filesystem permission circumvention exists. The most disturbing aspect of this is that the user went from having read access, which was allowed, to getting write access, which should never have been allowed. It wasn't allowed with the old permissions, and if the directory permissions had not been circumvented, it wouldn't have been allowed with the new permissions. I still think it's not very serious, because in order to exploit this, you need: - The people responsible for managing access to sensitive data to mishandle the initial protections on the file(s) - Those same people to later protect the so-called sensitive file in a way that doesn't really make a whole lot of sense - A process that already has an affected file open before the bizarre change in protections - The sysadmins to fail to notice people are accessing the files they just protected. You'd think if they just realized they had left permissions too open (and the data really was sensitive), they'd be paying attention... That's a lot of crazy. =8^) If your data really *is* sensitive, and this happens, you probably need to fire your sysadmin. Probably it should still be fixed though. I'm not sure what the point of making the files accessible via /proc is... It's good that open files are *recorded* there, but making the contents accessible from there seems unnecessary (and bad) to me, at least unless said access first determines the canonical file system path to the file (i.e. the one that the process used to open it), and checks the file access as it would normally, using that path. Still, I doubt I'll ever see this on any system I manage. If it were possible for a different user who wasn't already accessing the file to get access this way, that would be a very different matter... -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D
Attachment:
pgpJkLhxbJDFN.pgp
Description: PGP signature