From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7332 Path: news.gmane.org!not-for-mail From: =?UTF-8?B?0KDRi9GB0Yw=?= Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: Busybox on musl is affected by CVE-2015-1817 Date: Fri, 3 Apr 2015 11:40:55 +0700 Message-ID: <20150403114055.635173b5@r2lynx> 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> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1428036127 27451 80.91.229.3 (3 Apr 2015 04:42:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 3 Apr 2015 04:42:07 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7345-gllmg-musl=m.gmane.org@lists.openwall.com Fri Apr 03 06:42:06 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 1YdtQh-0002bU-ME for gllmg-musl@m.gmane.org; Fri, 03 Apr 2015 06:42:03 +0200 Original-Received: (qmail 15874 invoked by uid 550); 3 Apr 2015 04:42:02 -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 15843 invoked from network); 3 Apr 2015 04:42:01 -0000 X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,NO_RECEIVED, NO_RELAYS autolearn=ham autolearn_force=no version=3.4.0 In-Reply-To: <551D8776.80607@gmx.de> X-Mailer: claws_mail Xref: news.gmane.org gmane.linux.lib.musl.general:7332 Archived-At: On Thu, 02 Apr 2015 20:16:22 +0200 Harald Becker wrote: > On 02.04.2015 19:26, =D0=A0=D1=8B=D1=81=D1=8C wrote: > > Please *do not* touch setuid when it may save time and you from > > headcrash course when you appeared to lock yourself and your > > (embedded) device, for example. This already failed with selinux > > phones. >=20 > This was just a few theoretical words about that suid *root* problem: >=20 > 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 >=20 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. (Sorry if it's too ranty, but I already eaten by all this security dance on recent android phones) >=20 > > Nobody is vulnerable when you don't have setuid executables or > > mounted nosuid. No need to change the kernel. >=20 > Nobody talked about loosing the possibility to mount, etc. ... my=20 > suggestion would just work, as you start any such command with a sudo=20 > prefix and than let sudo decide if you are allowed to do the > operation. >=20 > Think of not enabling suid *root* mount for all user, but let a > wrapper check if the user is allowed to do the operation, and if so, > proceed to this as expected, let some others require to enter a > password, and deny the rest (depending on what is configured for your > system). >=20 I don't follow. I talked previous about disabling all setuids just by: mount -o remount,nosuid /some/mount in your rc.local, or adding (on sane systems) "nosuid" flag to fstab. Or just=20 find / -xdev -perm -4000 -exec ls -l '{}' ';' and select which you want to disable. (and same with -2000 for setgids) And yes, for other part about wrapper, this already works, but without any requirement to patch the kernel or making this patch mandatory. The wrapper even setups sane environment, overwrites argv0 when needed and programs not tied to /proc/self/exe checks or similar just work as expected. >=20 > > Because someone does not care about your security does not mean that > > you should accept and inherit that. Audit your filesystem and > > remove all setuid bits from all programs, move/rename them as > > prog.real and place a shell script in place which will call setuid > > wrapper which then will setreuid(uid, 0) then execve(). >=20 > This is what I'm currently doing, on my systems: A small wrapper > checks some things, and proceed to the called program afterwards. So > I do have only one suid *root* program, except some system related > stuff from a distro. >=20 > Except that my suggestion would just run such a wrapper automatically=20 > for suid *root* programs, it can easily be disabled in the kernel > (via a sysctl setting). So this would be an optional security > approach, for those who like this wrapper idea. 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. >=20 > ... but: >=20 > The discussion was, about the sense of suid, and I wanted to note, > the difference between suid *root* and suid *any other user*. >=20 setuid other user can be as same evil as setuid root. >=20 > > FYI I already implemented such a scheme and program and quite happy > > with it and I always know which executable is setuid on my system. > > It even has a rules which control various objects of access. The > > *only* problem is that writing such a program is a big pain because > > your code will be searched often for security bugs. So I'm in > > doubts. >=20 > And this is one of the reasons for my suggestion, all that would > benefit from a central wrapper, which is able to do sanity checks and > reject the most common caveats, e.g. letting suid *root* programs be > writable by anybody else than root. This central wrapper would be > more easy to inspect for security violations than every other program > (more eyes on a single part =3D higher security). Maybe. I still not sure about it. >=20 > ... but this was all theoretical: How I would try to solve some of > the known suid *root* problems. >=20 > Harald >=20 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.