Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ