Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 02 Apr 2015 20:16:22 +0200
From: Harald Becker <>
Subject: Re: Re: Busybox on musl is affected by CVE-2015-1817

On 02.04.2015 19:26, Рысь 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.

This was just a few theoretical words about that suid *root* problem:

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

> Nobody is vulnerable when you don't have setuid executables or mounted
> nosuid. No need to change the kernel.

Nobody talked about loosing the possibility to mount, etc. ... my 
suggestion would just work, as you start any such command with a sudo 
prefix and than let sudo decide if you are allowed to do the operation.

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).

> 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().

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 

Except that my suggestion would just run such a wrapper automatically 
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.

... but:

The discussion was, about the sense of suid, and I wanted to note, the 
difference between suid *root* and suid *any other user*.

> 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.

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 = higher security).

... but this was all theoretical: How I would try to solve some of the 
known suid *root* problems.


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.