[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150221152142.GY23507@brightrain.aerifal.cx>
Date: Sat, 21 Feb 2015 10:21:42 -0500
From: Rich Felker <dalias@...c.org>
To: oss-security@...ts.openwall.com
Subject: Re: Fixing the glibc runtime linker
On Fri, Feb 20, 2015 at 08:44:28AM -0800, Paul Pluzhnikov wrote:
> On Fri, Feb 20, 2015 at 1:22 AM, <Casper.Dik@...cle.com> wrote:
> >
> >>FWIW, relative RPATHs are quite fundamental to our test execution
> >>environment, and any patch that unconditionally ignores them would
> >>have to be reverted in our tree.
>
> It turns out I was mistaken: we don't use relative RPATHs after all.
>
> > But wouldn't that make the libraries and executables less reliable?
>
> Our testing infrastructure is described in some detail here:
> http://google-engtools.blogspot.com/2011/06/testing-at-speed-and-scale-of-google.html
>
> The essential problem is that the paths to all the libraries in the cloud
> are effectively unpredictable. They are however predictable relative to
> $ORIGIN, which is what we actually use [1].
${ORIGIN}-based RPATH is not subject to the same security issues as
cwd-relative RPATH. There are some issues to consider with suids
(malicious hardlinks, for example) but I believe these can all be
mitigated by having the whole device non-writable except by root or
enabling hardlink restrictions in the kernel.
> > They can pick up random libraries or cause some delays when one of the
> > relative paths points to a NFS mounted directory.
>
> We only build tests that way, not final binaries. Random libraries and
> NFS are not a concern for us, because the 'in the cloud' environment is
> tightly controlled -- we know exactly what files the test will see at
> runtime (relative to $ORIGIN).
>
> > Any reason you can't change to using LD_LIBRARY_PATH for testing?
>
> We used to use LD_LIBRARY_PATH, but it has several problems. Consider a
> Python or Java program that needs to load some C++ shared library, and
> also wants to fork off a separate C++ executable. Consider further that
> the python may be built for ix86, while the C++ executable may be built
> for x86_64.
>
> What should the LD_LIBRARY_PATH look like? Should it leak from python into
> C++ executable? It's complicated :-)
For exactly this reason -- that it's inherited -- LD_LIBRARY_PATH
really should not be used, or at least its use should be limited to
building and testing, not actual deployment. RPATH is a much more
appropriate tool.
Rich
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
