On Tue 2014-04-22 16:17:57, David Herrmann wrote: > Hi > > On Tue, Apr 22, 2014 at 3:49 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > > Anyone who opens a file read-only and sends it over SCM_RIGHTS is > > likely broken. They may think that it's read-only, so it can't be > > written, but this /proc/fd issue means that whoever receives it can > > reopen it. > > > > It's true that, if the inode doesn't allow the recipient write access, > > then the recipient can't reopen, but there are lots of cases where the > > inode can't reliably be expected not to allow write. For example, the > > inode could be unlinked, an O_TMPFILE file, a memfd handle, or in a > > non-world-executable directory, and the file mode should be respected. > > I think it's safe to assume that any object you create is never > world-accessible. So the worst you can get is 0600. So if we now take > your example, your patch doesn't fix the problem at all. Imagine two > processes, $sender and $receiver. If the receiver runs as a different > user as the sender, it cannot open /proc/self/fd/ writable due to > 0600. So the only problematic case is if both run as the same user. > However, in that case, the receiver can _always_ access > /proc/$sender/fd/ and thus still gain writable access to the object, > even if its own fd is read-only and your patch was applied. (ignoring > the fact that they can kill() and ptrace each other..) > > Protecting world-accessible objects by hiding them is imho wrong. And > protecting users against themselves is even worse. See the link for example where this matters in multi-user setting. Agreed, protecting file using its directory's permissions is not practice to be recommended, but we should not be breaking it. (And we are not breaking it if /proc is not mounted...) Enforcing read-only on file descriptor is IMO useful, and being able to work around it using /proc/self/fd is a security problem... 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
