[pacman-dev] Adding privilege levitation to pacman

[Eli Schwartz]

On 1/4/21 8:47 AM, Emil Velikov via pacman-dev wrote:
> Hello everyone,
> 
> For a while now I've been wondering about adding privilege elevation
> to pacman, or if you prefer to libalpm.
> In particular, one that uses polkit akin to systemd and various other tools.
> 
> The reason behind this is a multiple fold, but my main selfish wish is
> to get rid of yaourt. As you know, it is an "unsafe pacman wrapper"
> which is capable of a very basic elevation via sudo.

All of this seems like something I'm thoroughly uninterested in.

As you say -- "akin to systemd". The `systemctl` tool, like pacman, has 
multiple modes of operation, some of which require root. In the event 
the user neglects to run "sudo systemctl ...", it will essentially say, 
from a user perspective,

"hi, I notice you forgot to run me as root, but I need root. I will 
momentarily re-exec myself, using the polkit tool, to get root".

Then it prompts for root, most likely using a GUI dialog that grabs 
control of your entire screen.

Under the hood, it is actually depending on dbus and a javascript engine 
in order to pass messages to daemons that do "everything which needs 
root", which in pacman's case is... essentially everything, once you're 
in "install and remove packages" mode.

But the user experience of using polkit here is pretty simple: it lets 
you forget to use "sudo" and not need to re-run after an error.

I don't even see how this would let you get rid of yaourt, an AUR helper 
with the purpose of compiling AUR packages with one wrapper call.

The simple solution is to take this code in src/pacman/pacman.c:

         /* check if we have sufficient permission for the requested 
operation */
         if(myuid > 0 && needs_root()) {
                 pm_printf(ALPM_LOG_ERROR, _("you cannot perform this 
operation unless you are root.\n"));
                 cleanup(EXIT_FAILURE);
         }


and modify it to ALPM_LOG_WARNING:

you cannot perform this operation unless you are root. Rerunning 
{"sudo", "/proc/self/exe", argv...}

and exec() that for auto-retry-as-root. This then adds a hard dependency 
on sudo instead of polkit...

> Once that is complete, I have been itching to try and minimise the
> use/requirement of root, or as it's better known - apply the principle
> of least privilege.

But indeed we do, as Levente said, want to do separation of privileges. 
There ae a few things that don't *need* root, and operate on untrusted 
input, e.g. fields in unsigned databases, HTTP headers for 
http://mirror.randomuser.org/pub/archlinux/ and so on. Quite frankly, I 
don't believe these should be run as the invoking user either, but as a 
dedicated system user for privileged-but-not-root tasks. If we move 
GPGME verification of packages to a non-root user, that user better not 
be the current login user...

The solution here is, I believe, to run pacman as root, but drop the 
EUID to the system account user "libalpm" for a bunch of things before 
we finally get to extracting package contents to "/".

I don't see how polkit helps this goal. It assumes you have any 
intention of running some code as the login user; alternatively, it's 
just a very complex execlp("sudo", "sudo", "pacman", argv[1], argv[2], ...)

> Would either of the above be suitable for inclusion in pacman/libalpm?
> Having the thumbs-up, before writing and testing the code, would be
> appreciated.
If it involves running the non-root parts as a system (not login) user, 
then yes. i.e. the goal here is to make pacman more secure by 
*separation* of privileges.

By personal preference, hopefully not polkit. :p

Automatic *elevation* of privileges is not a goal, but if you implement 
the former in such a way that it also implements the latter, ok.

...

Merely reimplementing an AUR helper's complimentary "detect whether the 
command line arguments need root, and choose to invoke pacman using 
sudo", but not actually making pacman more secure, makes me uneasy...

... and implementing it via polkit gets my NACK because I don't believe 
it's the job of a CLI tool to display GUI windows for authentication, 
and I'm not going to bite my tongue and accept it if it doesn't even 
give us FS#65401 but is solely to implement a yaourt feature.

-- 
Eli Schwartz
Bug Wrangler and Trusted User

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