Welcome to the Pacman bug tracker. Please search the current bugs and feature requests before filing a new one! Use advanced search and select "Search in Comments".

* Please select the correct category and version.
* Write a descriptive summary, background info, and provide a reproducible test case whenever possible.

FS#62114 - [makepkg] is vulnerable to sudo caching attacks, and also it should use sudo in a safer way than now

Attached to Project: Pacman
Opened by Andrew Kotsyuba (avallac_h) - Friday, 22 March 2019, 12:51 GMT
Last edited by Allan McRae (Allan) - Friday, 22 March 2019, 22:19 GMT
Task Type Bug Report
Category makepkg
Status Closed
Assigned To Allan McRae (Allan)
Architecture All
Severity High
Priority Normal
Reported Version 5.1.3
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


I asked Allan McRae about this last week, but..

Summary and Info:

Currently, makepkg doesn't perform any checks to find whether it runs on tty with active sudo session or not. Due to the fact that many users use default sudo configuration, it could be dangerous to run makepkg with cached sudo credentials.

It is possible to run any command with a privilege escalation to the local root directly from the build scripts of the project you building.

Attached patch shows how, in my opinion, makepkg should handle sudo sessions.


* Sudo caching attack technique

* Sudo man-page

* Attack example using AUR helper's sudo loop (how practically sudo loop will be dangerous?)

Steps to Reproduce:

1. Using active sudo session.

1.1. Run 'sudo -l' to ensure that current user can run any command with sudo and sudo timestamp_timeout is greater than 0.

1.2. Run 'sudo -v', enter the password.

1.3. Try to build package using attached PKGBUILD.

2. Using makepkg -s.

2.1. Run 'sudo -l' to ensure that current user can run any command with sudo and sudo timestamp_timeout is greater than 0.

2.2. Uncomment depends= section in attached PKGBUILD.

2.3. Ensure that you don't have 'virtualbox-sdk' package installed or modify PKGBUILD by adding any package that doesn't installed on current host to depends.

2.4. Try to build package with 'makepkg --syncdeps'
This task depends upon

Closed by  Allan McRae (Allan)
Friday, 22 March 2019, 22:19 GMT
Reason for closing:  Not a bug
Comment by Allan McRae (Allan) - Friday, 22 March 2019, 13:15 GMT
I still say this is not a bug.

Either configure sudo to run only the commands you want or set the timeout to immediate. This "bug" is a choice the administrator makes for the convenience of sudo.

Or don't have sudo installed and makepkg will use su.

We should not drop privileges when the administrator has specifically not asked for it.
Comment by Levente Polyak (anthraxx) - Friday, 22 March 2019, 13:17 GMT
and how does it protect from malicious code? makepkg does nothing but executes code. if you run untrusted code in a trusted environment you are screwed anyway. Sure it may sound easy to call sudo and be done, but if you have write access to the users files anyway there are countless ways to achieve a privilege escalation later on if you use sudo or or other privilege elevation programs from the very same user.

Not saying it may not make sense to add this, its just not much of a security patch but a protection from _accidentally_ hazardous sudo calls in the buildchain underneath.
Comment by Dave Reisner (falconindy) - Friday, 22 March 2019, 13:49 GMT
I don't buy this as being a vulnerability in makepkg, nor do I agree with anything in the proposed fix. This is a general risk of sudo and if we actually care about this, we should be shipping a sudo configuration that has a reduced (0?) timeout (or convincing upstream to ship that as the default).

Also, makepkg only runs 'pacman' with elevated permissions. I'd say that's a feature, and one that reduces the attack surface. One might argue that it's more of a risk that we rely on a PATH lookup for pacman. We might also consider marking the 'run_pacman' function (and others?) as readonly in makepkg to avoid malicious PKGBUILDs from altering that behavior.
Comment by Eli Schwartz (eschwartz) - Friday, 22 March 2019, 14:49 GMT
This is a general risk of using AUR helpers that implement the vulnerable concept of a "sudo loop", which is exactly why makepkg implements no such thing, and why any time I see an AUR helper implement one without making it disabled by default, I warn them that they're dangerously overriding the user's security precautions in surprising and counterintuitive ways.

sudo can be configured to cache things, and cached sudo can be used by anything. This is hardly makepkg specific, I don't see why makepkg should add special handling for this administrator choice. (Every script or binary you install using makepkg, could *also* include attempts to run with sudo, like, well, just like the MITRE link you provided.)

Just don't build malware using makepkg -- do your due diligence and check the PKGBUILD for strange calls to sudo, and don't build surprising/unknown software, or you are far more likely to build a package that contains binaries with cleverly disguised backdoors than one with usually-very-easy-to-grep uses of sudo.

You could also go one step further and build in a makechrootpkg container, that doesn't have sudo available by default and can only execute pacman (which means malware would need to be targeted specifically at Arch and also contain a container privilege escape), or in a full VM. Although this still does not mean you can trust the compiled output of unknown code which you trust that little. But it does mean that your $HOME data is protected from imminent attack, and only becomes vulnerable once you run the packaged software, rather than immediately when you try to build it.

Either way, this is a much more robust separation of privileges than trying to nail the door shut on sudo which already has its own safeguards built into /etc/sudoers.
Comment by Andrew Kotsyuba (avallac_h) - Friday, 22 March 2019, 15:18 GMT
Well, you almost convinced me. But I have some remarks.

Allan McRae (Allan) wrote:
> This "bug" is a choice the administrator makes for the convenience of sudo.
But makepkg encourages this behavior. Shouldn't it at least warn about active sudo session? This will stop many people from doing dangerous things. Perhaps this will also cause some of them to configure sudo properly.

Dave Reisner (falconindy) wrote:
> Also, makepkg only runs 'pacman' with elevated permissions.
I think this is the main problem here (with that "only").

Since systemd is a mandatory part of Arch, maybe it's time to add some build isolation features to makepkg itself. Possible options:
* systemd dymanic users: systemd-run -p DynamicUser=yes -E HOME=$builddir
* chroot build: systemd-nspawn with --bind-ro

I know that I can use makepkg in that way by myself, but in this case all sense of options like '--syncdeps' is lost.

Also, I'm unsure about it, but maybe there's any way to use PolicyKit to allow makepkg call pacman. Could this be an alternative to sudo?

P.S. I almost completely agree with what Eli Schwartz (eschwartz) said.
Comment by Eli Schwartz (eschwartz) - Friday, 22 March 2019, 15:27 GMT
We will never add systemd integration to the pacman project. For a couple reasons including the fact that pacman is not tied to Arch Linux, and is in fact used in and supported on Windows, macOS, and BSD, in addition to multiple Linux-based Arch Linux derivatives that implement OpenRC. Moreover, imagine how embarrassed we would be if we had tied pacman to the use of SysVInit, and then wanted to migrate to systemd six years ago? I frankly do not see the advantage it brings, when any workflow-specific hardening (which BTW requires root to execute, thus dirtying the sudo timestamp outside of the daemonized container) can best be implemented by workflow-specific scripting.

BTW mentioning systemd DynamicUsers means you've drunk the pikaur kool-aid. makepkg has supported being run as sudo -u builduser makepkg, since day one, and does not need over-engineered init-specific service manager geared methodologies in order to perform its intended interactive use (which is not "run it as a service").

tl;dr pikaur as an AUR helper is a really bad example to draw inspiration from.
Comment by Andrew Kotsyuba (avallac_h) - Friday, 22 March 2019, 15:47 GMT
Ok, I got it. Thanks for the reasoned answers. Actually, Allan can already close this task.
Comment by Eli Schwartz (eschwartz) - Friday, 22 March 2019, 16:53 GMT
You could probably write a pkexec wrapper for Pacman, to be fair, but I don't know how you would elegantly work that into makepkg. I guess if you really like polkit you could create a dummy sudo command that sends everything to polkit. :p

I wouldn't want to prioritize it over sudo, because I'd guess most people are more familiar with and have a better sudoers config than a polkit config.