[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <551D8776.80607@gmx.de>
Date: Thu, 02 Apr 2015 20:16:22 +0200
From: Harald Becker <ralda@....de>
To: musl@...ts.openwall.com
Subject: Re: Re: Busybox on musl is affected by CVE-2015-1817
On 02.04.2015 19:26, Рысь wrote:
> 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.
This was just a few theoretical words about that suid *root* problem:
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
> Nobody is vulnerable when you don't have setuid executables or mounted
> nosuid. No need to change the kernel.
Nobody talked about loosing the possibility to mount, etc. ... my
suggestion would just work, as you start any such command with a sudo
prefix and than let sudo decide if you are allowed to do the operation.
Think of not enabling suid *root* mount for all user, but let a wrapper
check if the user is allowed to do the operation, and if so, proceed to
this as expected, let some others require to enter a password, and deny
the rest (depending on what is configured for your system).
> 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().
This is what I'm currently doing, on my systems: A small wrapper checks
some things, and proceed to the called program afterwards. So I do have
only one suid *root* program, except some system related stuff from a
distro.
Except that my suggestion would just run such a wrapper automatically
for suid *root* programs, it can easily be disabled in the kernel (via a
sysctl setting). So this would be an optional security approach, for
those who like this wrapper idea.
... but:
The discussion was, about the sense of suid, and I wanted to note, the
difference between suid *root* and suid *any other user*.
> 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.
And this is one of the reasons for my suggestion, all that would benefit
from a central wrapper, which is able to do sanity checks and reject the
most common caveats, e.g. letting suid *root* programs be writable by
anybody else than root. This central wrapper would be more easy to
inspect for security violations than every other program (more eyes on a
single part = higher security).
... but this was all theoretical: How I would try to solve some of the
known suid *root* problems.
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.
