From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7339 Path: news.gmane.org!not-for-mail From: Harald Becker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Busybox on musl is affected by CVE-2015-1817 Date: Sat, 04 Apr 2015 07:35:39 +0200 Message-ID: <551F782B.9090105@gmx.de> References: <20150330053150.GA484@brightrain.aerifal.cx> <20150331234810.GN6817@brightrain.aerifal.cx> <20150401074116.GN23636@example.net> <551BA847.3040609@gmx.de> <20150401084940.GO23636@example.net> <551D4A74.7070102@gmx.de> <20150403002656.11f75341@r2lynx> <551D8776.80607@gmx.de> <20150403114055.635173b5@r2lynx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1428125755 11875 80.91.229.3 (4 Apr 2015 05:35:55 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 4 Apr 2015 05:35:55 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7352-gllmg-musl=m.gmane.org@lists.openwall.com Sat Apr 04 07:35:55 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YeGkM-00024T-Jf for gllmg-musl@m.gmane.org; Sat, 04 Apr 2015 07:35:54 +0200 Original-Received: (qmail 15778 invoked by uid 550); 4 Apr 2015 05:35:52 -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 15755 invoked from network); 4 Apr 2015 05:35:52 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 In-Reply-To: <20150403114055.635173b5@r2lynx> X-Provags-ID: V03:K0:4oUEoTvsPPWBJpZOjVYzqKk0jeX5UdfWLuu4YGtyOchJD3vN2aj AMpBfuEJ55m6v8kXZCAXSkQ/1UbyL15tjsF96z5LjyQQ7sK2J39ruQ9je12Y0bi8EpeRt7t BNZQb080PV1o1lrst3D1pqICbHO/+gKj+Kaq3WfZZUW/GrQetwiGaSKuR4u6GTlH7OPXbb9 EN1GEM94LoFXMwnfCFChw== X-UI-Out-Filterresults: notjunk:1; Xref: news.gmane.org gmane.linux.lib.musl.general:7339 Archived-At: Hi, I don't want to follow this discussion into deep. It was a pure theoretical suggestion, and I don't think anybody is going to change something on this. ... but please read complete, you did something misunderstand: On 03.04.2015 06:40, Рысь wrote: >> Even if anybody would add this to the Linux kernel, it would only >> affect suid *root* programs, and run them through a wrapper program, >> something like sudo. Any other suid, and sgid would not be affected > > Well and losing a maybe crufty, cheaty but *always* working mechanism > which is expected to work on every Unix system. I think there is no > such a problem as setuid problem, root or user, when it is properly > handled. And what about, the kernel does this only, when a wrapper is configured (e.g by a sysctl like hotplug handler)? If you do not write anything to the sysctl variable you get the plain old suid *root* operation, but when the name of a wrapper program has been written to the sysctl variable *and* this program is not writable by any other than root, it does run through the wrapper ... *and* (in addition) when you write a "locked" to the sysctl variable, this feature can get locked in it's current state and no one may do further changes to this setting until kernel restart (for those who fear). ... let you get all you like, without hitting anyone staying on current behavior. > (Sorry if it's too ranty, but I already eaten by all this security dance > on recent android phones) I hate overdone security too. Beside being theoretical, my intention was an "optional" feature for those who like. > I don't follow. I talked previous about disabling all setuids just by: > mount -o remount,nosuid /some/mount This is something completely different, in no way affected by my intention ... but disables all suid usage, also suid to *none root*. > And yes, for other part about wrapper, this already works, but without > any requirement to patch the kernel or making this patch mandatory. ... but then you need to call the wrapper explicitly for each command, or replacing the command with a script calling the wrapper, loosing the possibility to block unintended suid *root* usage. > How about porting to other systems? There are ones with hardwired > assumptions about setuid all over their userspace source code. Of > course they maybe changed, but it will take *much* longer time than > just disable all setuids on average Linux system and forward them > through wrapper. a) differentiate between suid *root* and *suid none root* (the later won't get effected ever) b) my intention was an optional feature, for those who like, but it will only work with some slight help of the kernel, not affecting anybody who does not activate this > setuid other user can be as same evil as setuid root. When misdone, yes! Don't use it if you don't like it. > Well apart of modifying kernel for no reason this are good ideas if a > wrapper is simple enough to review. But more things evolve you need to > care about for programs then more you need code to add and more > potential bugs. But maybe it's just my impression because I did spent a > year developing one alone. When we talk here about a wrapper, please think of something like sudo, which is configurable, so any new program mean adding this program to the configuration, not more code to write. ... and the intended wrapper feature will only work with a little help of the kernel (else there is no increased security): Currently it does (rough): if program to exec is not suid exec the program with args else save real user id switch effective user id to the owner of the program exec the program with args My intention would be: if program to exec is not suid exec the program with args else save real user id switch effective user id to the owner of the program if program owner is root and wrapper program configured exec wrapper with name of program plus args else exec the program with args Where the wrapper does the security checking then exec to program with args, but may reject invocation before any code of the given program is executed. This was my suggestion. How would that hit anybody in any way, who does not write a wrapper name to the sysctl variable? Harald