[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <551D4A74.7070102@gmx.de>
Date: Thu, 02 Apr 2015 15:56:04 +0200
From: Harald Becker <ralda@....de>
To: musl@...ts.openwall.com
Subject: Re: Re: Busybox on musl is affected by CVE-2015-1817
Hi !
On 01.04.2015 10:49, u-wsnj@...ey.se wrote:
> Note that root does not need suid to drop its privileges.
Yes, but may benefit from the simplicity to do the drop:
Consider a suid program to a low privileged user, whenever that program
is called from any root process, the called program automatically drops
it's privileges. So you do not need to drop privileges in every possible
caller.
>> privileges of a different user (may be allowing access to some
>> files only by using specific commands).
>
> As soon as a program is setuid it has to be written for the purpose
> of very reliably checking and limiting what it does on behalf of
> who, independently of how it can potentially be invoked "out of
> context".
ACK. Any program going to be used with suid, or sgid has to be designed
for this.
> This is known to be hard, I believe it is harder to do reliably than
> e.g. issue a request to a daemon - talking about the complexity
> level.
Hard? A single getuid() call gives the user id of the calling user (real
user id), where the program runns with the priviledges of the effective
user (geteuid). So you can pick the real user id and check this against
a list of allowed users; same to getgid().
In addition: suid programs should set the owning group and permisions
carefully, e.g. fileuser:accessgroup owner=suid+x, group=x, other=none;
where the directories and files are owned by fileuser, with permissions
only to that user and nobody else.
A simple mechanism giving you a shield protecting your data from being
tampered by any other users programs (except root), but still all users
which are a member of group accessgroup can use your program, and access
the data in the intended manner.
> Thus the setuid program is to be designed to be as small as
> possible, presumably leaving all non-checking functions to (a)
> different executable(s).
True, for suid *root* programs, but otherwise I doubt. I see no such
need in e.g. the example above.
> Then the result becomes about as intricate as talking to a daemon,
> which can be run without any setuid.
I never told talking to a daemon is of no use, but many suid usages are
possible without the daemon overhead, and still not risking security
violations.
The big flaws are:
a) setting suid for a program never designed for that use
b) suid *root* (flaw by design)
IMO the case b should be blocked by the kernel and replaced with a more
reliable reaction:
Whenever the kernel detects a suid *root* program, it does not start
that program, but picks a configured path, for a statically linked
binary, with owner root, only executable by root, and no permissions to
others. That program shall be started by the kernel, giving the path to
the called program as first argument, then the remaining arguments.
This single *real suid root* program get than control (single point of
failure), and has to do the security relevant part (as you mentioned
above). Only when there is no doubt of usage, this single program drops
the privileges to the determined / required user, and then exec to the
intended program.
In other words, any program marked suid root is automatically invoked
through a program like sudo, which does the security checking, before
invoking any other code ... but without need of manually reentering that
sudo command on every program invocation.
This would be a very simple change in the kernel, giving a big step to
more security ... but still such things are missing :(
>> When used with care and as intended, suid and sgid is a nice
>> feature, but
>
> Unfortunately I can not really appreciate its beauty which appears to
> hide the complexity and/or move it to other parties (like the dynamic
> linker or the software maintenance infrastructure). Yes it "looks
> simple and efficient" but is it, really?
Not talking about suid *root*, which difficulties do you see? It's
beauty lies in it's simplicity and efficiency, but it's danger in the
widely misunderstanding and unintended usage.
>> nowadays there are too many Unix novices, who misunderstand or
>> misuse this, punching big holes in every security concern.
>
> Unfortunately even seasoned gurus easily create / fail to notice
> holes! :(
We are all humans and make mistakes, but a lot of those gurus forget
about this ... ok, they are gurus and no more humans ;)
See above: suid to *not root* is ok, suid *root* is flaw by design :(
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.
