[pacman-dev] [arch-general] Privilege separation in the pacman downloader (Was: Pacman Database Signatures)

[Allan McRae]

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.