The vendor software installs it setuid for you. It's not like they give you a choice, you just have to remove it later or be aware they did it.
Conversation
Replying to
But why would you run the vendor installer as root rather than as user or fakeroot?
3
1
Replying to
it prompts for elevated permissions on install, additionally most package managers like ArchLinux yourt include the binary as setuid root. I discovered this bug while hacking on the defcon2018 badge.
1
Worth noting that it's a third party package outside the officially repositories for people that aren't familiar with that. Lots of those unofficial packages make bad decisions, although they're just packaging the results of the installer in this case.
2
2
Sure, this is what's happening, but it's irresponsible on the distro's part. A modern distro should have a pretty absolute policy of no suids outside the core packages, or at least not in contrib packages that aren't subject to the level of review main-repo ones are.
1
1
5
It's a completely third party package, not one in a distribution contrib repository. Third party packages can be outright malicious and it doesn't even need to be subtle. It's a bad idea to use AUR helpers like yaourt since they encourage blindly trusting third party code.
2
2
OK, I don't understand everything about how Arch/AUR does stuff, and I'll probably catch a bunch of other dists in this criticism too...
2
1
But I think it's reasonable to say that users do not generally know, and should not be expected to know, whether third-party package installers run poorly-vetted or unvetted code as root. The package install systems should be designed such that they can't.
1
The package build should run as a temporary sandbox user, and stage in a DESTDIR. Then the actual install phase should verify that no paths owned by other stuff or with global impact (like /etc/*.d) are written before actually moving the staged files into place.
1
The makepkg tool does use fakeroot, and the more robust wrapper for it used in the devtools package runs it in a container to have a consistent, isolated build environment. There's a source and package audit tool (namcap) which devtools runs before/after to catch SOME issues.
1
It's unrealistic to catch any possible malicious thing that a package can do. Packages can have an arbitrary install script for creating their users/groups, etc. The namcap tool is meant to catch mistakes. It notifies about setuid/setgid binaries, some missing mitigations, etc.
Most users are just running makepkg directly rather than using the devtools wrappers used for the official distribution packaging. It's a good idea to use devtools even if you aren't a developer though. Package build scripts can have a lot of dumb mistakes and you might miss it.
1
Packages have no business creating users or groups or messing with any sort of system-level singletons.
1
That's how packages work on every traditional distribution though. They aren't isolated apps like an apk on Android. They get to install to every global directory and run arbitrary code in an install script. Installing to default bin / lib paths is arbitrary code exec anyway.
2
Show replies