From: Harald Becker <ralda@gmx.de>
To: musl@lists.openwall.com
Subject: Re: Re: Busybox on musl is affected by CVE-2015-1817
Date: Sat, 04 Apr 2015 07:35:39 +0200 [thread overview]
Message-ID: <551F782B.9090105@gmx.de> (raw)
In-Reply-To: <20150403114055.635173b5@r2lynx>
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
next prev parent reply other threads:[~2015-04-04 5:35 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-30 5:31 Rich Felker
2015-03-31 19:07 ` Denys Vlasenko
2015-03-31 23:11 ` Justin Cormack
2015-03-31 23:51 ` Rich Felker
2015-03-31 23:48 ` Rich Felker
2015-04-01 7:41 ` u-wsnj
2015-04-01 7:52 ` Raphael Cohn
2015-04-01 8:11 ` Harald Becker
2015-04-01 8:49 ` u-wsnj
2015-04-02 13:56 ` Harald Becker
2015-04-02 17:26 ` Рысь
2015-04-02 18:16 ` Harald Becker
2015-04-03 4:40 ` Рысь
2015-04-04 5:35 ` Harald Becker [this message]
2015-04-02 18:36 ` u-wsnj
2015-04-03 4:51 ` Рысь
2015-04-03 10:31 ` [OT] setuid (Re: Busybox on musl is affected by CVE-2015-1817) u-wsnj
2015-04-02 15:38 ` Re: Busybox on musl is affected by CVE-2015-1817 Rich Felker
2015-04-02 18:02 ` u-wsnj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=551F782B.9090105@gmx.de \
--to=ralda@gmx.de \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).