[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    Re: [BusyBox] vodz telnetd applet
From:       Adam Slattery <aslattery () sunriselinux ! com>
Date:       2001-09-19 20:50:10
[Download RAW message or body]


On Wed, 19 Sep 2001, David Kimdon wrote:

> We make busybox setuid root and for most applications we will drop
> privilages right before calling the applet's main.  We have the same
> amount of code that needs to be audited as the trustybox method
> (busyobx.c, applets.c and then any privilaged applet's code).

I'm not sure why everybody is under the impression that we need to audit
all of busybox if it is made suid root.  There truely isn't much code that
gets executed from the beginning of main() until the execution of an
applet.  The privileged applets would certainly need to be audited, but
most of them are so small that this would not be hard.

> looked around for discussions of what I could be missing, and
> http://www.freebsd.org/security/ has a note:
> 
>   * Just because you drop privileges somewhere, it does not mean
> that no exploit is possible. The attacker may put the necessary code
> on the stack to regain the privileges before executing /bin/sh.
> 
> It isn't clear to me if that is relevant.

No, this is not relevant when privileges are dropped correctly.  Under
linux, this is done with setuid(2), which is a POSIX documented function.
The problem only occurs when a program drops the effective uid but not the
real uid, which can be very useful but no effect on security.

Quoting the man page:

       If the user is root or the program is setuid root, special
       care must be taken. The setuid function checks the  effec-
       tive  uid  of  the  caller and if it is the superuser, all
       process related user ID's are set to uid.  After this  has
       occurred,  it is impossible for the program to regain root
       privileges.

I see no reason why applets needing privileges should be in a seperate
binary. There would be no security benefit.

- Adam Slattery




[prev in list] [next in list] [prev in thread] [next in thread]