From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2993 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Will musl work as a lsb alternative? (was Re: [musl] re: musl setup attempt) Date: Thu, 28 Mar 2013 08:12:29 -0400 Message-ID: <20130328121229.GZ20323@brightrain.aerifal.cx> References: <20130327032032.GS20323@brightrain.aerifal.cx> <1364444921.18069.1@driftwood> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1364472771 9710 80.91.229.3 (28 Mar 2013 12:12:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 28 Mar 2013 12:12:51 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2994-gllmg-musl=m.gmane.org@lists.openwall.com Thu Mar 28 13:13:18 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ULBhb-0006qE-84 for gllmg-musl@plane.gmane.org; Thu, 28 Mar 2013 13:13:07 +0100 Original-Received: (qmail 17764 invoked by uid 550); 28 Mar 2013 12:12:42 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 17756 invoked from network); 28 Mar 2013 12:12:42 -0000 Content-Disposition: inline In-Reply-To: <1364444921.18069.1@driftwood> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:2993 Archived-At: On Wed, Mar 27, 2013 at 11:28:41PM -0500, Rob Landley wrote: > >> it is possible to use the path/to/libc.so 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