On Tue, Apr 22, 2014 at 8:03 AM, David Herrmann <dh.herrmann@xxxxxxxxx> wrote: > Hi > > On Tue, Apr 22, 2014 at 4:33 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: >> On Tue, Apr 22, 2014 at 7:17 AM, David Herrmann <dh.herrmann@xxxxxxxxx> wrote: >>> 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. > > Which kernel-interface creates world-writable objects if a reasonable > umask like 022 is set? That is an incredibly large "if". Does Xorg change its umask when it starts? Whenever you write a setuid program, do you reset the umask? Will every user of memfd_create who makes a read-only fd pointing at the same thing remember to reset the umask? How about libraries that *can't* safely mess with umask because it's not thread-local? > >>> 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. > > Are you sure? Note I wrote /proc/$sender/fd/ not /proc/$receiver/fd/. > The lookup on /proc/$sender/fd/ is done with the file of the _sender_, > which obviously is writable. Sorry, I misread that. This is a problem that people who design non-uid-manipulating sandboxes have to handle. Or they can use pid namespaces. --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
