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.
Conversation
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.
2
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
They can drop in binaries / libraries to the default binary / library paths, script execution paths, etc. that will get automatically loaded / run by programs run by root. There is no limit on what needs to be blacklisted. Programs bring their own ways of auto executing stuff.
1
Not unless they clobber or take precedence in path search over a name that already exist, which should be caught at install time by conflict checks. Other than that the best they can do is typosquat.
1
Lots of software will load more libraries if they detect their presence, will run binaries if they detect their presence and offer ways of having hooks, pluggable configuration, etc. Distributions can't realistically use a blacklist system to handle all of this.
This is true of some things, but it's really bad design, and not likely to be true of anything you'd run as root or much you'd run on a real multi-user system as opposed to a single-user managed workstation. (It's mostly bad gui apps.)