What the hell do I need busybox for?

Message

henri · Post by **henri** » Thu Mar 05, 2009 3:08 am

Hi folks,

I know what busybox is and what it's normally for.

We installed a "pretty" secure server the last three days and I had to notice that busybox was also installed.
Can please someone tell me what's the reason why busybox was installed?

I do not use genkernel nor is our kernel modules-enabled. - And we don't use any ramdisks.

I didn't notice it before but it seems it's installed on servers and also on desktop machines which were optimised by the use of USE flags.

In my eyes this is a really big security-hole. How do I get rid of it without hacking the gentoo's portage and USE flag guidelines?

If you have any hints, please drop me some lines,
many thanks in advance,

yours Henri

Post by Hu » Thu Mar 05, 2009 3:38 am

A static busybox is an excellent repair tool when the system is in bad shape. Why do you consider it a security hole?

nmp0906 · Post by **nmp0906** » Thu Mar 05, 2009 1:13 pm

To keep your box busy. Seriously, do you want a lazy box? Especially a "pretty" secure one?

<Seriousness>
Busybox is a toolkit. Its used on a lot of platforms. Even my DD-WRT router has a version of it, and I'd like to consider it "pretty" secure. Claiming busybox is a security issue is similar to claiming any other basic toolkit (gentoolkit?) is a security hole. The simple answer is no.
</Seriousness>

henri · Post by **henri** » Thu Mar 05, 2009 1:50 pm

Hi folks,

first of all, there might be a missunderstanding: I do not consider busybox itself a security hole!

Second: Your wrt router, like other small boxes like a Terastation, has ONLY busybox, which replaces the set of full command binaries to save disk and ram space.
That makes sense.

But why should I have a busybox on my servers where creating a symlink by a cracker may suffice in some case to get every command he wants?
If the busybox binary itself would be replaced or set suid, noone would probably notice that!
Allright, I could tighten security for busybox also by chmodding it to 700, but why should I? It is simply not needed for the system.
"equery depends busybox" also says, no package is depending on it.

So my question is still not answered. I didn't explicit request a busybox install and it is not needed on a system with coreutils installed.
If a server is so corrupted or broken that I would need busybox to repair it, a completely new server-install would be the correct thing to do.
Anything else might be something to do at home with your desktop, but wouldn't be an accurate action for a server accessible throught the internet.
How could some of the coreutils be broken on a server? Only by a crack, eg. a cracker replaced the binaries on a amd64 system with x86 binaries.

So again: Why is busybox installed by default?

Many thanks for your answers,
yours Henri

Polynomial-C · Post by **Polynomial-C** » Thu Mar 05, 2009 2:09 pm

I disagree. I don't want to completely reinstall servers in case some update of coreutils/util-linux/net-tools/bash (to just name the most commonly needed packages) failed miserably.
Also there are other problems that can arise which could render some often used binaries unuseable. The infamous blocker against e2fsprogs/ss/com_err comes to my mind which could make wget fail in some constellations. Or a dying harddrive where you want to rescue some data but the /bin/cp command is corrupt.
I only needed busybox a few times but in those cases I always was happy to have it installed on the servers I have to administer (and where I only have limited control about update-/backup-procedures).
Finally, you have the opportunity to influence the abilities of busybox drastically. Just have a look at the busybox ebuilds, where you can find a mini-howto about how to customize busybox the way you want to have additional/less abilities in it.

sera · Post by **sera** » Thu Mar 05, 2009 2:39 pm

Code: Select all

qgrep -H sys-apps/busybox
app-doc/repodoc/repodoc-0.1.0.ebuild:	|| ( sys-apps/gawk sys-apps/mawk sys-apps/busybox )"
...

So repodoc optionally depends on it.

It gets installed because it's part of the system set. And I guess that's a reasonable default as those bothered by busybox being installed are very likely capable of removing it.

dreadlorde · Post by **dreadlorde** » Thu Mar 05, 2009 2:48 pm

For this

Code: Select all

default 0
timeout 3

title Gentoo Linux 2.6.28-r2
root (hd0,6)
kernel /boot/bzImage-2.6.28-gentoo-r2-2 root=/dev/hda7 resume=/dev/hda5 quiet vga=791 init=/bin/busybox

In case you fuck everything up.

nmp0906 · Post by **nmp0906** » Thu Mar 05, 2009 2:55 pm

You know, if you don't want it, you can just # emerge -C busybox and move on. Hell, even mask it if you don't want it to pop back up again. I agree with the aforementioned views of having it as a recovery tool and default part of the system set. For most users, this is acceptable. However, you are special. And so is Gentoo. So use its full power of customization! That is what it is there for.

henri · Post by **henri** » Thu Mar 05, 2009 5:27 pm

Hi again,

many thanks for your fast answers.

O.K. I don't have repodoc installed so I guess it has already been in the stage tarball.

Again, I know exactly what busybox is and that it is neccessary on some systems and might be additionally useful in some special cases.
But in my opinion, these cases only fit to a home-user environment. On a server, I would never! try to repair a whole system with the use of busybox if the coreutils were corrupted because there might only be very few cases how coreutils may be broken or corrupted on a running server system. And if one of these cases occure, you better should bring the server down immediately!

Yes, I already emerged -C it, but I simply was not aware until yesterday that it was installed additionally althought I use gentoo almost since Daniel brought it to the public.

@ nmp0906: Hmm, maybe I am special

because I have to nearly guarantee my customers that the server won't be cracked and believe me, it happened before a few times althought we don't use kernel modules, mount var, home, tmp etc nosuid, notail, nodev and some partitions noexec; We make use of psad and fail2ban and also do some other things to make a system pretty secure but nevertheless it happened in the past.
Crackers might be script kiddies, but might also be reel geeks. I've seen a lot of tricks to corrupt a system now and am aware they are alwasy a step in front of me and the bigger your customer is, the more potential breakins you will notice.
I might be a bit paranoid so my opinion is that a system should be as secure as it may be from the point of installation on.
Maybe you're all right that many people use busybox in the case of emergency, but I think it should be optional, maybe mentioned in the gentoo installation handbook like this:
"If you like to have the most system commands in one small single binary for the case you break your system while installation or an update, you might also want to install busybox to have all commands handy for the case..."

One of the reasons we use gentoo is that it normally does NOT install unneccessary tools and programs by default like the most other distros do.

Anyway, many thanks for your replies,
my intention was not to dicuss if it is a useful tool or not, I know it is in special cases.
I think I will extract a stage tarball myself for testing to see if busybox is already in there.

Thanks to all, yours Henri

henri · Post by **henri** » Thu Mar 05, 2009 5:45 pm

Ah, sorry, I forgot...

@ Polynomial-C: You do untested updates on a running server-system so it might break the whole server and leave a whole company with x branch offices without email, website and shopsystem for more than at least one day? - What it might probabely take if you were not aware of the upcoming problems. - Oh my god... I don't want to be your customer.

As I mentioned, it might be an additional tool for your home-development-station, but never for a serious server system.
And let's be honest: Most linux/gentoo installs are server installs althought also all of my desktops are gentoo.

If you need something to fix your server, you better install a small recovery partition with all the neccessary tools.
So while you repair your server it has not to be online with all that broken stuff at all!

Think of it,
yours Henri

Polynomial-C · Post by **Polynomial-C** » Thu Mar 05, 2009 8:28 pm

henri wrote:@ Polynomial-C: You do untested updates on a running server-system

Of course I don't do this. But sometimes the devil hides in details. I was struggling several times with updates that went perfectly well on my test sytems but broke on the servers then. Fortunately most of these servers I have to administer are non-critical.

poly_poly-man · Post by **poly_poly-man** » Thu Mar 05, 2009 8:31 pm

initrd's. If you use genkernel or like pain, you need it.

timeBandit · Post by **timeBandit** » Thu Mar 05, 2009 9:35 pm

poly_poly-man wrote:initrd's. If you use genkernel or like pain, you need it.

henri, in the original post, wrote:I do not use genkernel nor is our kernel modules-enabled. - And we don't use any ramdisks.

(readingSkills)--

poly_poly-man · Post by **poly_poly-man** » Thu Mar 05, 2009 9:50 pm

timeBandit wrote:
poly_poly-man wrote:initrd's. If you use genkernel or like pain, you need it.
henri, in the original post, wrote:I do not use genkernel nor is our kernel modules-enabled. - And we don't use any ramdisks.
(readingSkills)--

op tl;dr

Post by Hu » Fri Mar 06, 2009 4:32 am

henri wrote: So my question is still not answered. I didn't explicit request a busybox install and it is not needed on a system with coreutils installed.
If a server is so corrupted or broken that I would need busybox to repair it, a completely new server-install would be the correct thing to do.
Anything else might be something to do at home with your desktop, but wouldn't be an accurate action for a server accessible throught the internet.
How could some of the coreutils be broken on a server? Only by a crack, eg. a cracker replaced the binaries on a amd64 system with x86 binaries.

So again: Why is busybox installed by default?

I answered your question first off.

A new install can be overkill. I once had a system lose libattr.so due to an oversight with emerge --depclean. Coreutils was set as USE=-xattr, but it had linked to it anyway. Thus, losing libattr.so broke coreutils. Busybox let me repair the system in about five minutes and do so without halting the running environment. I cannot reinstall a server that quickly.

I do not understand why you are worried about an attacker making busybox setuid. If you are watching for unexpectedly setuid programs at all, you would catch busybox as quickly as any other intruding binary. If an attacker can add the setuid bit, what prevents him from uploading a static busybox to a location of his choosing?

timeBandit · Post by **timeBandit** » Fri Mar 06, 2009 5:52 am

henri wrote:If a server is so corrupted or broken that I would need busybox to repair it, a completely new server-install would be the correct thing to do.
Anything else might be something to do at home with your desktop, but wouldn't be an accurate action for a server accessible throught the internet.
How could some of the coreutils be broken on a server? Only by a crack, eg. a cracker replaced the binaries on a amd64 system with x86 binaries.

The first two statements are sweeping generalities based on your opinions and preferences, not universal truths. Yours is not the one correct way to operate a server, nor is mine, nor is Hu's, etc. There are best practices of course, but which practices to follow is a matter of choice, necessity or both.

As for the last, you have forgotten the simplest possibility of all: human error. Yours. Some day a mistake in routine maintenance, despite all your care, may leave you with a wrecked server. You might find yourself wishing you'd kept tools to restore service to your customers faster than a reinstall.

None of us can tell you how to run your business. If your customers expect you to forego certain tools in the name of ultimate security, fine, that's their choice and yours. But remember one size doesn't fit all: busybox is part of the system set because many people do not share your philosophy--they consider it an almost indispensable tool.

sera · Post by **sera** » Fri Mar 06, 2009 12:21 pm

O.K. I don't have repodoc installed so I guess it has already been in the stage tarball.

You could just type "emerge -pv system" and busybox will be listed. When booting the first time into a gentoo installation a usual thing to do is "emerge -e system" after checking the packages listed. In your case man, man-pages and groff for instance might be some other candidates

.

However I agree completely that if it's not needed then it doesn't belong on a hardened box, but hardening a box means also actively search and remove unneeded stuff (and this is much easier in gentoo than other distros I know of). Unfortunately what's unneeded is also a matter of taste.
Setting up a system as you described needs a hole lot of customization so this one is really a small fly.

Polynomial-C · Post by **Polynomial-C** » Fri Mar 06, 2009 12:29 pm

The only concern I have with any package being in the system profile is that I cannot get rid of it through /etc/portage/profile/package.provided file.
Removing the package and adding it to package.provided leads to the following (in the context completely wrong) error message:

Code: Select all

zeromancer:~ # emerge -Cq busybox >/dev/null


!!! 'sys-apps/busybox' is part of your system profile.
!!! Unmerging it may be damaging to your system.

zeromancer:~ # echo "sys-apps/busybox-99" >> /etc/portage/profile/package.provided 
zeromancer:~ # emerge -uDpqv @world

WARNING: A requested package will not be merged because it is listed in
package.provided:

  sys-apps/busybox pulled in by 'world'

This problem can be solved in one of the following ways:

  A) Use emaint to clean offending packages from world (if not installed).
  B) Uninstall offending packages (cleans them from world).
  C) Remove offending entries from package.provided.

The best course of action depends on the reason that an offending
package.provided entry exists.

zeromancer:~ #

The "pulled in by 'world'" is plain wrong...

sera · Post by **sera** » Fri Mar 06, 2009 8:27 pm

The "pulled in by 'world'" is plain wrong...

World pulls in system witch then pulls in busybox. But why adding it to package.provided shouldn't work beats me completely.