On 5/2/20 2:08 pm, Eli Schwartz wrote: > On 2/2/20 4:59 PM, Christopher W. via arch-general wrote: >> Right now, pacman is taking untrusted input from the internet as root. >> That's very bad. Most of the comments I've seen say that an attacker >> could hold back vulnerable packages, but this is assuming the attacker >> does not have bigger plans. The pacman tool is not immune to bugs in >> the way it parses the database files. It has no privilege separation >> in the download/parsing code as far as I can see (apt and others have >> had this for a long time) so it's really an even more dire situation. >> Pacman should not perform any operations as root until it has verified >> the signature of all files being used to install/upgrade the packages, >> but it currently does everything (downloading, verifying, etc) as root. >> >> I'd like to get a discussion going about how and when these two issues >> could be resolved so that all Arch users can be safer. Thanks. > > This is a more interesting topic to me, personally (as opposed to the > first half of your email which I responded to separately) because it's a > proposal for something that pacman itself could do better, without > waiting on distro policy. > > It's also a discussion that will go nowhere, and then die alone, on > arch-general, since pacman development and proposals happen exclusively > on the pacman-dev mailing list. Therefore, I am cc'ing the pacman-dev > mailing list so that this has a chance to go somewhere. :) > > Since I'm unfamiliar with apt and other tools, what exactly do they do? > Given pacman/apt/your-choice-of-package-manager must somehow write to a > cachedir, e.g. /var/cache/pacman/pkg, it would need a dedicated download > user, which would then exclusively hold ownership of the cachedir.
Well... My current patchset creates a temporary directory in /tmp/alpm-XXXXXX to download database into, only replacing original copy when verified (assuming verification is available). That is a location that a non privileged process could create and write to. The downloaded file could them be moved into place as root. Then is it just a matter of wrapping this entire thing in a setuid() calls? > pacman is one big binary at the moment, it doesn't fork+exec to run > collections of binaries implementing different parts of the package > manager (which is actually a plus when it comes to speed), so this might > entail major re-architecturing of that part of pacman. Doing it for > external XferCommand programs could be a start. As a rule, I accept no patches implementing features in the XferCommand path that are not in the internal downloader.
