linux-kernel - Re: [PATCH 0/3] vfs: plug some holes involving LAST_BIND symlinks and file bind mounts (try #5)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20091124012027.GA14645@shareable.org>
Date:	Tue, 24 Nov 2009 01:20:27 +0000
From:	Jamie Lokier <jamie@...reable.org>
To:	Jeff Layton <jlayton@...hat.com>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
	pavel@....cz, miklos@...redi.hu, viro@...IV.linux.org.uk
Subject: Re: [PATCH 0/3] vfs: plug some holes involving LAST_BIND symlinks and file bind mounts (try #5)

Jeff Layton wrote:
> I certainly don't want to break existing apps. That said, applications
> that are depending on /proc/pid symlinks to allow them to bypass
> directory permissions or access files that aren't in their namespace
> would seem to be unsafe, no?

I think we can mostly agree on that :-)

> I think all we can reasonably do is try to clearly lay out how these
> symlinks are intended to work. I think it's logical that the result of
> following these links should be more or less the same as if you were to
> resolve the results of the readlink.
> 
> Is there some reason that we should expect them to provide anything
> more? Do you have apps in mind that you think will break with this
> change?

Anything which compiled with and uses the openat(), mkdirat()
etc. emulation in gnulib (formerly known as libiberty), and anything
using the same technique.

You know, GNU coreutils and other obscure things :-)

Of course there are real system calls for that, now, but there are
still compiled programs that don't know about the real system calls.

The same technique (traversing /proc/self/fd/N) is used on Solaris, by
the way.  It's probably worth keeping a modicum of compatibility with
whatever Solaris does.

> If you think this is unreasonable, perhaps you could suggest an
> alternative?

I have, two mails up - did you read it? - and in the previous threads
which resulted in the bugtraq.

Please tell me why that approach does not work, thanks.

> If this approach is reasonable, there is one thing I think that I'm
> pretty sure will need to be fixed.

It's not reasonable for /proc/self/fd/N because that has historically
been a way to follow a directory (like openat) or dup() an open file
without sharing the seek offset, which is useful for multithreaded
code.

Same goes for /proc/self/exe: That has historically been a way to read
your own executable, e.g. for self-extracting executables, executables
with additional data glued on.  That breaks if the executable at the
link target is not yourself.

But just to prove we've been over this before and never came to a
consensus or conclusion:

http://lkml.org/lkml/2008/3/23/3

(the whole thread is worth a read, but Denys Vlasenko's remarks are
especially relevant).

And for those who remember 2.0 :-)

http://lkml.indiana.edu/hypermail/linux/kernel/9609.2/0371.html

-- Jamie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/