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

[Eli Schwartz]

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.

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.

Is this a topic you're interested in exploring?

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/pacman-dev/attachments/20200204/ade55373/attachment.sig>