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.
Conversation
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.
2
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.
Thus:
Quote Tweet
Replying to @DanielMicay and @hackerfantastic
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...
1
1
Even without an Android-like privilege model where apps are isolated from privileges of the invoking user, you can and should have a model where packages never have more privileges than any user who invokes their binaries (i.e. not root during install).
2
Show replies
I'm not saying I think it's a good model. I think it's better to have a standard base system that's entirely first party and not cobbled together out of ad-hoc package and configuration choices, with well-defined sandboxes for non-core components regardless of the install source.
1