On Tue 2014-04-22 17:19:42, David Herrmann wrote: > Hi > > On Tue, Apr 22, 2014 at 4:31 PM, Pavel Machek <pavel@xxxxxx> wrote: > > Such as here? > > > > http://www.securityfocus.com/archive/1/507386 > > Thanks, that's the first real example someone mentioned. > > Quoted from your link: > > > The reopen does check the inode permission, but it does not require > > you have any reachable path to the file. Someone _might_ use that as > > a traditional unix security mechanism, but if so it's probably quite rare. > > In other words, the bug you describe is that /proc/pid/fd/ allows > access to objects without a reachable path to the only _real_ > filesystem link. But isn't the same true for openat()? I don't think openat helps you. This is what we are talking about, it is easy to reproduce. Can you reproduce it without /proc mounted? I think that chmod 700 . should stop you. Openat seems no worse than just placing cwd there... 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 pavel@toy:/tmp/my_priv$ echo this file should never be writable > unwritable_file # lock down directory pavel@toy:/tmp/my_priv$ chmod 700 . # relax file permissions, directory is private, so this is safe # check link count on unwritable_file. We would not want someone # to have a hard link to work around our permissions, would we? pavel@toy:/tmp/my_priv$ chmod 666 unwritable_file pavel@toy:/tmp/my_priv$ cat unwritable_file this file should never be writable pavel@toy:/tmp/my_priv$ cat unwritable_file got you # Security problem here Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- 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
