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

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 

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

This was my suggestion. How would that hit anybody in any way, who does 
not write a wrapper name to the sysctl variable?


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.