[Toybox] Toybox vs Bustbox

Rob Landley rob at landley.net
Tue Jan 7 09:03:29 PST 2025


On 1/7/25 09:22, enh wrote:
>> I guess "setpriv" would be interesting to someone who actually uses
>> selinux? Or no, is this capability bits?
> 
> interestingly, it looks like "all of the above" --- it's a single command
> that lets you mess with ids, groups, environment, capabilities, selinux
> labels, etc... an interesting idea in theory, but this is the first i've
> ever heard of its existence.

Debian installs it by default from util-linux, git log says busybox 
added it in 2017.

Argues for implementing it as is, I suppose, except... setpriv -d lists 
"supplementary groups" but busybox --help doesn't say how to CHANGE 
them? Ah, the man page says there's a --clear-groups and --groups which 
are LONGOPTS ONLY and thus very annoying... One of the options just 
references "man 3 initgroups" which can't be right. "For safety" we 
don't select a consistent default behavior because we are cowards...

   --pdeathsig keep|clear|<signal>

     Keep, clear or set the parent death signal. Some LSMs, most notably
     SELinux and AppArmor, clear the signal when the process'
     credentials change. Using --pdeathsig keep will restore the parent
     death signal after changing credentials to remedy that situation.

Really? (I am not implementing app-armor profiles without someone 
actually using it asking me to.)

I don't need --reset-env we have an "env" command already.

   Be careful with this tool — it may have unexpected security
   consequences. For example, setting no_new_privs and then execing a
   program that is SELinux-confined (as this tool would do) may prevent
   the SELinux restrictions from taking effect.

Security plumbing in a nutshell: "caution, this is just as likely to 
make it worse".

Ok, reading the man page is arguing AGAINST implementing this mess as 
is. Maybe I _should_ just do a "contain" command where I can use single 
letter options for stuff. (You kind of have to in order to chroot() and 
_then_ drop privileges. And an actually secure-ish chroot uses 
pivot_root() for reasons I've vented about _at_Linus_. Why doesn't 
chroot also do chdir? So it can be insecure. No other reason as far as I 
can tell...)

Yeah, there's other holes: linux-vserver.org/Secure_chroot_Barrier

(Somewhere in my notes I have a survey of other "contain" style commands 
people were doing...)

>> I've had a hard time taking
>> those seriously since:
>>
>> https://forums.grsecurity.net/viewtopic.php?f=7&t=2522
>>
>> But I guess it's vaguely adjacent to "unshare"? (Which toybox already
>> has. I've meant to do a "contain" command that set all that nonsense
>> from one command line, so you can make a wrapper script to enter a
>> container...)
>>
> 
> ...and annoyingly, the one thing that setpriv is _missing_ is the unshare
> stuff :-(

They stack. My debootstrap launch wrapper is:

sudo env -i USER=root TERM=linux SHELL=/bin/bash LANG=$LANG 
PATH=/bin:/sbin:/usr/bin:/usr/sbin unshare -Cimpuf chroot newroot /init

Modulo there was a discussion on here about me needing to fix up toybox 
unshare to handle some no-root case the kernel had added, which I 
couldn't test at the time until after I'd upgraded to a new OS release, 
but after the reinstall I don't have the URL to the message bookmarked 
and haven't managed to dig it up again since? (I have the todo item 
reminding me to do it, but have to dig through the archive to find the 
old message. Was it mailing list, or github, or private email, or 
something somebody said you can now do on the kernel list and I went "I 
should implement that", or...?)

For that matter, was it unshare or nsenter?

> yeah, for that i think you just have to scan down
> 
> https://landley.net/toybox/help.html
> 
> and
> 
> https://man.archlinux.org/man/busybox.1.en#COMMAND_DESCRIPTIONS
> 
> and see if there's anything you care about.
>
> (busybox.net seems to be down atm.)

Up for me. https://busybox.net/downloads/BusyBox.html

> or just "suck it and see", which is basically what Android did for the host
> build.

Alas real world use is the only REAL test, which is why I need to get 
the linux from scratch build working again...

Rob


More information about the Toybox mailing list