[oe] [PATCH] Fix busybox SUID support

[Phil Blundell]

On Fri, 2010-02-26 at 23:26 +0100, Bernhard Reutner-Fischer wrote:
> SUID_DROP applets do just that before the individual applet_main is called,
> i.e. drops privs. But whatever..
> If you really think you want to build the thing twice then i'd try
> FEATURE_SHARED_BUSYBOX, fyi.
> $ size 0_lib/{busybox,libbusybox.so.1.17.0.git}
>    text	   data	    bss	    dec	    hex	filename
>    1379	    520	     16	   1915	    77b	0_lib/busybox
>  339569	   6705	   8552	 354826	  56a0a	0_lib/libbusybox.so.1.17.0.git
> 
> duplicating 2k is better than duplicating all the innocent rest, but maybe
> that's just me..

Whether this is a good idea or not rather depends on what you're trying
to protect against.  The threat scenarios for a setuid busybox basically
fall into two categories:

a) user invokes an applet which shouldn't be setuid, but busybox fails
(for whatever reason) to drop its privs and allows the applet to run in
root context

b) user invokes an applet which is intended to be setuid, busybox
correctly retains the elevated privs while running it, but there is some
bug or vulnerability in the code which causes unwanted results

If you're primarily worried about case (a) then building two copies of
the frontend which share a common libbusybox, one setuid and one not,
probably is a reasonable thing to do.  However, as you say, busybox does
already have a fairly robust mechanism in place for dropping privs when
they are not wanted by a particular applet and hence the threat from
this side seems to be quite low anyway.

If you are primarily worried about case (b) then the easiest way to
mitigate the threat is to reduce the amount of code which is linked in
to the setuid binary (either statically or dynamically) and hence the
amount of code that you need to audit for security hazards.  In that
situation, linking with a shared libbusybox would not help, since you
still have essentially the whole of busybox to worry about and you might
as well just stick with a single large binary.  Instead you would be
better off making a minimal, standalone busybox binary which contained
the bare minimum of code that was required to fulfil its setuid
functions.

p.