[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 3 Apr 2015 11:40:55 +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 20:16:22 +0200
Harald Becker <ralda@....de> wrote:
> 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
>
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.
(Sorry if it's too ranty, but I already eaten by all this security dance
on recent android phones)
>
> > 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).
>
I don't follow. I talked previous about disabling all setuids just by:
mount -o remount,nosuid /some/mount
in your rc.local, or adding (on sane systems) "nosuid" flag to fstab.
Or just
find / -xdev -perm -4000 -exec ls -l '{}' ';'
and select which you want to disable. (and same with -2000 for setgids)
And yes, for other part about wrapper, this already works, but without
any requirement to patch the kernel or making this patch mandatory. The
wrapper even setups sane environment, overwrites argv0 when needed and
programs not tied to /proc/self/exe checks or similar just work as
expected.
>
> > 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.
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.
>
> ... but:
>
> The discussion was, about the sense of suid, and I wanted to note,
> the difference between suid *root* and suid *any other user*.
>
setuid other user can be as same evil as setuid root.
>
> > 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).
Maybe. I still not sure about it.
>
> ... but this was all theoretical: How I would try to solve some of
> the known suid *root* problems.
>
> Harald
>
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.
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.
