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 15:56:04 +0200
From: Harald Becker <>
Subject: Re: Re: Busybox on musl is affected by CVE-2015-1817

Hi !

On 01.04.2015 10:49, 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

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

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


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.