[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130328121229.GZ20323@brightrain.aerifal.cx>
Date: Thu, 28 Mar 2013 08:12:29 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Will musl work as a lsb alternative? (was Re: re:
musl setup attempt)
On Wed, Mar 27, 2013 at 11:28:41PM -0500, Rob Landley wrote:
> >> it is possible to use the path/to/libc.so <command> trick or an ELF
> >> editor to circumvent this. Currently, you might want to include most
> >> of the libraries if you go for this.
> >
> >Yes, you could definitely do this with a shell script wrapper too. It
> >would work a lot better if we added command line options to the
> >dynamic linker, so that you could do something like:
> >
> >exec /opt/myapp/bin/ld-musl-$(ARCH).so.1 --libpath /opt/myapp/lib -- \
> > /opt/myapp/bin/myapp "$@"
>
> You're aware that other C libraries let you switch this off because
> it renders the noexec flag to mount completely useless, right? Or
> did you have a fix for that?
You can do the same thing via LD_PRELOAD, and probably a number of
other ways. In my opinion, trying to prevent a user who already has a
unix account and non-restricted shell from running their own binaries
is usually a misguided security effort. If somebody is using musl in a
situation where they can really benefit from this, or if it just makes
their boss who knows nothing about security happy, it would be super
easy to patch out these features. If at some future date we have
switchable build features (but see the past threads on this topic for
some thoughts on the scope of such), and there's demand, locking down
the dynamic linker/loader could perhaps be one of them.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
