busybox/tinylogin suid security issues
chuckmeade at mindspring.com
Wed Dec 21 22:36:04 UTC 2005
Thanks for the response. Thanks to Mike F. also for his response.
> > 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)
> 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".
Good. Thanks for the explanation above.
> > 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
> This is all a 1.2 issue.
It seems that overall, using the suid support in busybox is a fine
alternative to having the separate binary with suid privileges. I don't
see any security vulnerabilities, and it has got to be smaller than
having the overhead of 2 binaries.
> > 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?
The copyright on the book is 2003. Mike F. also pointed out that the suid
support in busybox is newer than that.
I appreciate the information.
More information about the busybox