On Sun, 2009-10-25 at 02:29 +0000, Anton Ivanov wrote: > We have been having a back and fourth on this with a couple of people. > It has not shown up on BUGTRAQ yet because it is sitting in the > moderator queue. > > First of all, any permission bypass is bad. Principle of least surprise. > > Second, the important thing here is that directory permissions are > ignored. Sure, the current directory permissions are irrelevant when you already have a file descriptor - you can carry on reading and writing to the file if the file permissions let you. The problem here is that /proc/self/fd, unlike dup(), can be used to upgrade a read-only file descriptor to a read-write file descriptor based on the file's current permissions. > Whatever the reason, that is not good. The case shown by Pavel > is an extreme example (using 666), but you can most likely have a less > extreme example where this can be put to "good" use. > > Third, there is a non-zero size class of applications where it is likely > such idiocy like 666 protected one level above by dir to be found - > ported from Windows. Under windows, locking is non-advisory and apps > tend to scribble "under themselves". So if you open a file with an > exclusive Read/write lock nobody can read/write it regardless of > permissions. When a program gets ported to unix developers (or the > porting toolkit) replaces the code with flocks or fcntl which are > advisory and the file becomes nicely accessible. No such code in debian > proper, but that does not mean that there is no such code out there in > the wild. I imagine such applications are already totally insecure. > Fourth, during the discussion it was claimed that this does not work on > Linux proper. In a listing of /proc/self/fd the files appear with read and/or write permissions depending on the file descriptor mode. But when a process tries to open them they are treated as symbolic links, which have no permissions of their own. This is fairly obvious when looking at the code and it's not something we change. > I have some doubts about the claim, but cannot verify it > (I am off on holiday in an hour or so). It maybe Debian specific or > specific to a patch which Debian and more than one other distro is using > (ptrace comes to mind). I personally do not think that is the case, > however it is worth checking and if it is coming from the ptrace patches > double check if they do not introduce something worse than that > somewhere. I don't know what patches you're talking about. Ben. -- Ben Hutchings The obvious mathematical breakthrough [to break modern encryption] would be development of an easy way to factor large prime numbers. - Bill Gates
Attachment:
signature.asc
Description: This is a digitally signed message part