[pacman-dev] [arch-general] Privilege separation in the pacman downloader (Was: Pacman Database Signatures)
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
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.
On 2/4/20 11:08 PM, Eli Schwartz wrote:
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?
I've opened a feature request for this: https://bugs.archlinux.org/task/65401 -- Eli Schwartz Bug Wrangler and Trusted User
participants (2)
-
Allan McRae
-
Eli Schwartz