[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sat, 04 Apr 2015 07:35:39 +0200
From: Harald Becker <ralda@....de>
To: musl@...ts.openwall.com
Subject: Re: Re: Busybox on musl is affected by CVE-2015-1817
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
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.
