Arch Linux

It strikes me as a particularly bad idea.
Isn't it pretty much equivalent to giving a root shell to anybody?

(it's the setuid bit, btw. the sticky bit would be 'chmod +t', and won't do much on a regular file).

You also need a configuration file for busybox, for proper work of the applets (su, passwd, mount, ...)

> Isn't it pretty much equivalent to giving a root shell to everybody?
Ok, it is not...

it is safe, as long as:
* busybox is bugfree
* busybox is compiled with FEATURE_SUID (Arch's busybox is)
* if busybox is compiled with FEATURE_SUID_CONFIG (ditto); you don't do anything stupid in the /etc/busybox.conf

> You also need a configuration file for busybox, for proper work of the applets (su, passwd, mount, ...)
It seems that busybox will use the compile-time defaults[*] if there is no entry for the applet in the /etc/busybox.conf, so it's not stricly necessary. It's still useful to further restrict access to root privs. (you can also use it to relax access if you really want to; including really stupid things like making 'cp' run as root).

[*] That is: retain root privs if the applet has BB_SUID_REQUIRE/MAYBE; drop them if it has BB_SUID_DROP (see include/applets.src.h)

I put busybox-1.19.2-2 with suid bit into community-testing, please try it.

Works fine for me. Thanx

Why was this reverted and replaced by a post_install message?

I don't see any commit message describing why this was changed.

I think it was https://bugs.archlinux.org/task/26312

currently it checks suid bit before update and restores permission after update
https://git.archlinux.org/svntogit/community.git/tree/trunk/busybox.install?h=packages/busybox

May be we should reimplement it with namcap if it is possible.

im still not quite convinced having suid on busybox is the perfect idea through, all applets work if you have root privileges / root shell acquired in any of the multiple possible ways. That should be sufficient for most repair cases anyway without opening additional attack surface for cases where its literally impossible to somehow get uid=0 rights.
Even busybox developers are not an exceptional never failing entity: https://www.cvedetails.com/vulnerability-list/vendor_id-4282/Busybox.html
not that it matters much but im not aware of any distro shipping it with suid. My opinion is that we shouldn't neither.

Not every CVE is equal... IIUC busybox first checks to see if the applet at argv0 (or argv1 if called as `busybox $applet`) is meant to have root permissions either via the hardcoded defaults or /etc/busybox.conf, and then immediately drops permissions before doing anything else.

It is difficult to see how, for example, tar directory traversals would be able to manipulate suid.

AFAIK the busybox developers are pretty good about their suid dropping code, so in any situation where it matters, a vulnerability in util-linux su which *is* suid, and rightly so, would be just as dangerous... so is it any more dangerous to give busybox su the same rights and risks?

It doesn't make much sense for someone who wanted to replace util-linux su with the busybox version, to use the util-linux version in order to gain permissions to use the busybox version. ;)

It wasn't meant as a proof that it makes privilege escalation already, its a prove that nobody is un-failable and security issues exist, either way just omit that its not what is part of the logical argumentation at all:
Security/risk and vulnerability assessment are not to rate the trust in the ability of a developer, its about resources, privileges and possible boundaries of a software so it doesn't matter how much we heard that they are pretty good.

Arguing that we already have something with suid is nothing but a broken window principle. Just because there is something doesn't mean we can freely give it to everything. Suid is something that should in fact be given as little as possible and the optimum would be to aim to get rid of them totally (see outside issues affecting this like stack-clash) and adding more because we already have such is not how this will ever happen.

People who want to use busybox su without root shell (by opening a root shell or by early dropping into busybox shell as root for early rescue stage f.e.) or without util-linux su via sudo (just because) are the minority and they can still totally achieve this by adding the suid bit which will then be preserved. The su applet is just a micro portion of the busybox suite in total, which provides over 150 different applets/functions to users, and this particular specific use-case is still easily achievable by opt-in while it exposes less surface by default then opt-out. And again: busybux this way can still be used sufficiently easy as a system rescue tool without the need of the su applet and suid bit.

My opinion is still, keep it without suid, just fix the current non-safe way to preserve the bit.

I definitely get where you're coming from, though it is worth noting that the suid bit will *not* in fact be preserved by pacman.
To be honest, a user-provided pacman hook for those that want it, to restore permissions would work fine, and might in fact be preferred as it would be idempotent. Fortunately, we have since added pacman hook support, so users can now fix this themselves!

If we do not want to commit to making busybox suid, we should not try to handhold the user either.

All things being considered, I think we should drop the install script and add wiki documentation instead.
I'd be happy to fix this, alongside the outstanding  FS#56391 . Really, I like busybox and would be willing to comaintain this package if sergej doesn't mind. :)