On Tue, Apr 22, 2014 at 7:17 AM, David Herrmann <dh.herrmann@xxxxxxxxx> 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. Can you explain what you mean? I think that it's completely *unsafe* to make this assumption unless you actually take some explicit action to make sure it's correct. > 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..) Incorrect. That is exactly what my patch changes. > > Protecting world-accessible objects by hiding them is imho wrong. And > protecting users against themselves is even worse. Protecting users against themselves (i.e. other things with the same uid) when they create namespaces and use seccomp filters is important. --Andy -- 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
