busybox/tinylogin suid security issues

[Rob Landley]

On Wednesday 21 December 2005 14:20, Chuck Meade wrote:
> I have been searching for information on the security aspects of the
> tinylogin logic that was integrated into busybox.
>
> In Karim Yaghmour's book "Building Embedded Linux Systems", Karim
> states that he builds tinylogin as a separate component from busybox,
> since it needs suid/root privileges.

You can still do that.  Build one busybox with the suid applets, and another 
with the non-suid applets, and have the relevant symlinks point to the 
different executables.

> He does not want to give suid 
> privileges to the busybox binary itself, due to the security concerns
> of running ls and cat (for example) at root level.

If you enable suid support, we drop privilidges first thing when running an 
app that shouldn't be suid.

If you look at include/applets.h you'll see a lot of stuff like this:

#ifdef CONFIG_ADDGROUP
        APPLET(addgroup, addgroup_main, _BB_DIR_BIN, _BB_SUID_NEVER)
#endif

The fourth field is for the SUID stuff.  That indictes that the applet 
"addgroup" should never inherit suid privs from busybox's main().  The actual 
code that drop the privilidges is in applets/applets.c (if you want to audit 
it yourself).

And if you grep applets.h for "SUID" and then filter out "NEVER" (which means 
drop all priviledges), you get:

       APPLET_NOUSAGE("busybox", busybox_main, _BB_DIR_BIN, _BB_SUID_MAYBE)
        APPLET(crontab, crontab_main, _BB_DIR_USR_BIN, _BB_SUID_ALWAYS)
        APPLET(ipcrm, ipcrm_main, _BB_DIR_USR_BIN, _BB_SUID_ALWAYS)
        APPLET(ipcs, ipcs_main, _BB_DIR_USR_BIN, _BB_SUID_ALWAYS)
        APPLET(login, login_main, _BB_DIR_BIN, _BB_SUID_ALWAYS)
        APPLET(passwd, passwd_main, _BB_DIR_USR_BIN, _BB_SUID_ALWAYS)
        APPLET(ping, ping_main, _BB_DIR_BIN, _BB_SUID_MAYBE)
        APPLET(su, su_main, _BB_DIR_BIN, _BB_SUID_ALWAYS)
        APPLET(traceroute, traceroute_main, _BB_DIR_USR_BIN, _BB_SUID_MAYBE)
        APPLET(vlock, vlock_main, _BB_DIR_USR_BIN, _BB_SUID_ALWAYS)

Which really isn't that much.

Some quick analysis: busybox and traceroute are "MAYBE" (which means keep 
privs if you have them) and crontab, ipcrm, ipcs, login, passwd, su, and 
vlock are "ALWAYS" (meaning this app can't run as non-root).

Once I add "user" mount support, mount becomes another "ALWAYS".

> However, Busybox can have configurable suid privileges per applet,
> using the file /etc/busybox.conf.  This seems to be just as secure
> as Karim's method.  Plus it seems much smaller than his method of
> adding more programs to the filesystem, so that they can have their
> individual suid bits set.

We also have our own flags.  The conf file is a bit like sudo, it specifies 
who can run what.  (To be honest, I think we should probably just bite the 
bullet and have a sudo applet.)

By the way, the main downside of all this "drop priviledges" stuff is that if 
you make a standalone shell, you can't get sudo _back_ without doing an exec.  
(This is another reason we exec /proc/self/exe to run standalone shell 
applets.)

This is all a 1.2 issue.

> Does anyone see any advantage of using Karim's method (separate
> tinylogin apps with suid bits set) over the Busybox method (suid
> configured in /etc/busybox.conf)?

Tinylogin is the old way of doing it.  How old is his book?

> Thanks,
> Chuck

Rob
-- 
Steve Ballmer: Innovation!  Inigo Montoya: You keep using that word.
I do not think it means what you think it means.