[PATCH 1/2] Allow BusyBox to be built without a list of applet names

[Timo Teras]

On Sat, 30 Apr 2016 21:07:46 +0700
James B <jamesbond3142 at gmail.com> wrote:

> On Sat, 30 Apr 2016 09:36:02 -0400
> Jody Lee Bruchon <jody at jodybruchon.com> wrote:
> 
> > On April 30, 2016 9:07:42 AM EDT, Tito <farmatito at tiscali.it>
> > wrote:  
> > >
> > >
> > >On 04/30/2016 02:58 PM, Jody Lee Bruchon wrote:  
> > >> On April 30, 2016 8:39:24 AM EDT, Andreas Oberritter  
> > ><obi at opendreambox.org> wrote:  
> > >>> On 30.04.2016 09:16, Laurent Bercot wrote:
> > >>>
> > >>> Even worse, consider a busybox binary that someone expects to  
> > >contain a  
> > >>> real command like cat or hexdump, which it doesn't. The
> > >>> colliding  
> > >hash  
> > >>> of this command could map to a command that accepts the same
> > >>> command-line arguments but destroys data, like mkfs.* or rm.
> > >>>  
> > 
> > It doesn't matter. If the user is throwing arbitrary command names
> > at BusyBox, the user deserves whatever they get as a result.   
> 
> Ummm, no. If a program isn't expected to destroy data (like "dd" or
> "mkfs" do), then it should never fail in a way to destroy data.
> Somebody who accidentally calls "busybox get-some-status /dev/sdb"
> won't expect that it will end up mkfs-ing this disk, if this
> "get-some-status" command is not implemented.

Especially since many of the applets can be disabled in config. So if
I use system and do not fully know the config, I can do "busybox
lsattr /" and up calling "rm". Changes of this are even higher since
--install is not supported so I need to manage the list of symlinks
somewhere else, or just use "busybox applet" syntax.

Yes, odds are still small. But designing a system where it can do
unpredictable things is bound to fail sooner or later.

Not to mention the gaping security hole potential.

Personally I would never approve patch like this.

/Timo