[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150403002656.11f75341@r2lynx>
Date: Fri, 3 Apr 2015 00:26:56 +0700
From: Рысь <lynx@...server.ru>
To: musl@...ts.openwall.com
Subject: Re: Re: Busybox on musl is affected by CVE-2015-1817
On Thu, 02 Apr 2015 15:56:04 +0200
Harald Becker <ralda@....de> wrote:
> 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 :(
Please *do not* touch setuid when it may save time and you from
headcrash course when you appeared to lock yourself and your (embedded)
device, for example. This already failed with selinux phones.
Nobody is vulnerable when you don't have setuid executables or mounted
nosuid. No need to change the kernel.
Because someone does not care about your security does not mean that
you should accept and inherit that. Audit your filesystem and remove all
setuid bits from all programs, move/rename them as prog.real and place
a shell script in place which will call setuid wrapper which then will
setreuid(uid, 0) then execve().
FYI I already implemented such a scheme and program and quite happy with
it and I always know which executable is setuid on my system. It even
has a rules which control various objects of access. The *only* problem
is that writing such a program is a big pain because your code will be
searched often for security bugs. So I'm in doubts.
>
>
> >> 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.
