embedded control panel - can this work?
from_busybox_maillist at dexdyne.com
Tue Jan 18 11:41:00 UTC 2011
This is a long ramble, for which any advice is welcome, but there are
some specific questions -
Assume a standard version of the current busybox.
Suppose a C program which is running as web, gains root uid, and then
invokes a shell.
Will that busybox in the shell refuse to allow the date to be set, as the
user isn't "really" root? Or would the extra levels of obfuscation fool
it into allowing it?
If the answer is "you're screwed" then is there any alternative scheme
whereby a web browser can DIRECTLY, and reasonably safely, invoke busybox
commands such as date and reboot?
I've heard of stuff like wheel, but as far as I can see that doesn't
help.... you never become "real root"
We have a small remote embedded system.
It has a web-browser interface, which allows the user to do things one
wouldn't normally expect a web interface like Amazon.com to do such as:
set the date
reboot the system
reconfigure all the networking interfaces to new settings
At present the CGI invokes a C program, all running as web.
That C program has code in it to obtain root uid ( currently faulty, but
I know how to fix it ) and then start a shell to run the "date", "reboot",
Reconfiguring networking can include a long list of things like ifconfig,
dhcp, OpenVPN, pppd etc. I'm not sure I can write down a full list of the
commands it might use now or in future versions!
Plus it wants to start long-running processes like dhcp which really do
need to be root-privileged.
The original programmer didn't know how to fix the faulty code, so he
resorted to setting the suid bit on the busybox 0.6 exe. That got the
system working, and he didn't tell anyone how he'd kludged it.
I'm now trying to port this lot to busybox 1.17, ( and soon to a computer
which doesn't use busybox ) , and the trick of setting the suid bit on
the busybox exe won't work with a vanilla busybox any longer.
I guess I can recompile busybox without the new code, and reproduce the
insecure situation we had with busybox 0.6
That would make my new unit work, but it means that I have to rebuild the
busybox on any/every computer I want to port it to.
It might look convenient that on a "big linux" I seem to be able to set
the suid on the "date" exe, and have it run for user web.
But it's not an easy solution, as I'd have to identify and set the suid
bit on ( and keep identifying in future ) every command used in network
To say nothing of the security implications!
I think the only way to do it half-properly on non-busybox system is to
fix the server-side C code so it gets root uid and then shells. At least
then anyone logging in as web or fred can't run everything.
I could force the more complicated functions like network reconfig to do
a full reboot to implement the changes, but these boxes are remote,
unattended, and communicating over GPRS. The fewer unforced reboots the
happier I am.
Now I could go and fix the code, so that my C program successfully gains
root privileges, and starts a new shell, and calls a vanilla busybox 1.17
to do it's functions...
But if busybox will still block access to setting the date etc, that
doesn't fix a lot.
My colleague here says the only way we fix this properly is to create a
service process, which runs as root, and accepts messages from the
server-side C program, running as web, and then executes the required
functions. I'm beginning to think he's right, but it's a tedious lot of
More information about the busybox