Hi! > >pavel@toy:/tmp$ uname -a > >Linux toy.ucw.cz 2.6.32-rc3 #21 Mon Oct 19 07:32:02 CEST 2009 armv5tel GNU/Linux > >pavel@toy:/tmp mkdir my_priv; cd my_priv > > Attacker opens my_priv and waits. ... > >pavel@toy:/tmp/my_priv$ cat unwritable_file > >this file should never be writable > > Attacker uses openat() to open and modify the "private" file. > > >pavel@toy:/tmp/my_priv$ cat unwritable_file > >got you > ># Security problem here > > > >Unexpected? Well, yes, to me anyway. Linux specific? Yes, I think so. > > Not quite, as described above: there's a permissions race which > allowed the attacker to open the my_priv directory. Once you > have an fd on a directory it's possible to open any file inside > without a full-path permissions check. If you created the directory > using `mkdir -m 0700` (eliminating the race) then you should be safe. Ok, if linux honors O_SEARCH on directories, then you found problem with my example. Congratulations, you were the first one :-). I could present more complex example, pavel passing guest read-only file descriptor over unix socket. At that point, you would not be able to play with openat. OTOH, that example would be complex & ugly :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
