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...
Conversation
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.
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
This property is needed in order for it to be safe for an administrator to install packages that a user has requested (and trusts) without the administrator also having to trust that package, and limits the damage to the user(s) who want it.
1
Needing an administrator to install packages globally that are in everyone's configuration / library / binary paths is a problem. It should be possible to install a package only for a specific user, even without having support for properly sandboxing everything.
I completely agree with this, but there may be advantages to having the admin install it (automated updates, single point of knowledge of what's installed, reproducing the setup without dependence on user files, ...).
1
1
nixos.org/nix/ has a compelling approach to these things and supports exposing package installations only to users that wanted to install the packages even though it is actually installed globally.
1
1
Show replies