[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALoOobPz3A6spHVWGaiZc_zvWtf0oUizwCXRk4T=CFu+WbJMFg@mail.gmail.com>
Date: Thu, 19 Feb 2015 23:25:01 -0800
From: Paul Pluzhnikov <ppluzhnikov@...gle.com>
To: Tim Brown <tmb@...35.com>
Cc: oss-security@...ts.openwall.com
Subject: Re: Fixing the glibc runtime linker
On Thu, Feb 19, 2015 at 10:30 PM, Tim Brown <tmb@...35.com> wrote:
> On Friday 20 February 2015 01:38:31 Paul Pluzhnikov 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.
>
> That's useful to know. Is that for setuid binaries or more generally?
We don't build/test setuid binaries, so if you only enforced the
restriction for setuid binaries, then we wouldn't have any problem.
> As I
> noted, it would be dead easy only to use the part of the patch that rejects
> them for the former only. Although as I said, that offers less protection.
> Would that make the patch more consumable?
Yes, that form would work for us.
> Another option would be to have
> something like /etc/suid-debug which could flag that an override is in
> operation.
You could also reject relative RPATH for all binaries, unless a
specific LD_ALLOW_RELATIVE_RPATH or some such environment variable is
set.
We could then set that environment variable in the test execution
environment, but not outside of it.
I guess my point is that we must have the ability to use relative
RPATH in testing, so either we'll have to revert your patch, or make
an escape hatch of some sort.
--
Paul Pluzhnikov
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.
