[oe] TinyLogin

[Holger Schurig]

> - security auditing is difficult, since the large amount of
> code-sharing in busybox makes it hard to determine which
> functions can potentially be called from a setuid context;

Can I assume from this that you didn't actually look at busybox's 
source-code?

In libbb/appletlib.c, function "check_suid(int applet_no)":

if (APPLET_SUID(applet_no) == _BB_SUID_ALWAYS) {
        /* Real uid is not 0. If euid isn't 0 too, suid bit
         * is most probably not set on our executable */
        if (geteuid())
                bb_error_msg_and_die("must be suid to work"
                                     "properly");
} else if (APPLET_SUID(applet_no) == _BB_SUID_NEVER) {
        xsetgid(rgid);  /* drop all privileges */
        xsetuid(ruid);
}


The function is called by run_applet_no_and_exit(), which is the 
only way to run an applet. So it's always called.

Maybe you'll also look at include/applets.h, where we have lines 
like:

USE_BRCTL(APPLET(brctl, _BB_DIR_USR_SBIN, _BB_SUID_NEVER))

and then you can check the definition of APPLET_SUID() in 
include/busybox.h


From what I gathered in just a few minutes, this doesn't seem to 
be "hard to determine".

Also I fear that many people that now insist "This is no 
thoroughtly done security examination" --- and which are 
right ---  never actually didn't do a proper security 
examination of tinylogin either.



> - the relatively high rate of code churn, combined with the
> large amount of code re-use and the fact that there's no
> inbuilt guard against accidentally mixing privilege domains,
> means that any audit would be likely to need repeating
> frequently.

This seems to be not true from what the code says. ALL calls to 
busybox applets go via the above quoted function, it's not the 
the case that each applet individually drops it's priviledge --- 
and that therefore it's easy for one applet to forget dropping.


>
> > If you are really paranoid and don't want to do this, build
> > two busybox binaries with different applets in them
>
> That does help with the first two points above, but not with
> the latter two.

> And, if you're going to build a separate binary for the login
> utilities, you might just as well have gone on using tinylogin
> in the first place. 

Except that TinyLogin is end-of-life and won't get bugfixes from 
upstream.