[pacman-dev] Adding privilege levitation to pacman
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. 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. 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. Thanks Emil
On January 4, 2021 2:47:20 PM GMT+01:00, Emil Velikov via pacman-dev <pacman-dev@lists.archlinux.org> wrote:
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.
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.
Just a small pointer but in general separation of privileges is something desired and currently being tracked here: https://bugs.archlinux.org/task/65401 In general the idea of that tracking issue is to only elevate privileges for very specific parts of the code flow that require higher privileges and run everything else in an unprivileged context. Cheers Levente
On 04-01-2021 14:47, Emil Velikov via pacman-dev wrote:
Hello everyone, Hey :) 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.
Privilege separation could be a nice feature for pacman, like Levente said. However, if you want pacman to be run as non-root and then automagically gain required privileges to overwrite system files through polkit, I don't think that is something I would want. For starters, `pacman -U` with a custom package would allow you to overwrite anything with anything. In general, requiring root to use pacman is a good thing. If you were to add restrictions on the allowed commands or require group membership, why not simply use custom sudo rules? You can configure sudo to allow certain commands without asking for a password if you really want to (but I wouldn't recommend that for pacman). The opposite does sound nice: have pacman start as root and then drop privileges for parts of the code where it is not required.
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. 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.
If you just want `pacman` to automatically be `sudo pacman`, you can just add a shell alias or wrapper script in your $PATH :)
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.
Thanks Emil
Regards, Maarten
On Mon, 4 Jan 2021 at 16:11, Maarten de Vries via pacman-dev <pacman-dev@lists.archlinux.org> wrote:
On 04-01-2021 14:47, Emil Velikov via pacman-dev wrote:
Hello everyone, Hey :) 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.
Privilege separation could be a nice feature for pacman, like Levente said. However, if you want pacman to be run as non-root and then automagically gain required privileges to overwrite system files through polkit, I don't think that is something I would want.
For starters, `pacman -U` with a custom package would allow you to overwrite anything with anything. In general, requiring root to use pacman is a good thing.
How does using polkit make any difference? The existing "run-as-root" workflow will remain unchanged.
If you were to add restrictions on the allowed commands or require group membership, why not simply use custom sudo rules? You can configure sudo to allow certain commands without asking for a password if you really want to (but I wouldn't recommend that for pacman).
I'm aware of such sudo hacks, but that's all they are. Gruesome, do not scale and error prone (-Sy requires root, -Si foo does not, while -Syi foo is also a thing).
The opposite does sound nice: have pacman start as root and then drop privileges for parts of the code where it is not required.
There are more or less 3 pieces of software on my systems that use this approach - systemd (PID 1 so starts as root, although I doubt it drops priv), Xorg (prime example of new, well written and secure code) and OpenVPN (I think it no longer runs as root with last version) To clear any ambiguity I was being sarcastic in the Xorg case. You are welcome to test how fragile the approach is (as implemented in Xorg) - it's close to impossible for the initial code (run as root) to attribute for each permutation, that will be triggered later on at runtime. So currently it drops permissions for a wide range of cases which actually require root. After a casual chat with some systemd and dbus devs - I was pointed at polkit. With polkit a) gaining and revoking root is trivial, b) it integrates nicely (better than gpg/pinentry) with tty, gnome, kde, etc, while it also c) provides for a consistent user experience.
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. 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.
If you just want `pacman` to automatically be `sudo pacman`, you can just add a shell alias or wrapper script in your $PATH :)
I'm not sure if you're joking or trolling here. I am aiming for "least privilege", moving from yaourt which absolutely sucks in that department, with pacman being a tiny bit better. Last but not least, to reiterate pacman will work as original when the system lacks polkit all together. Thanks Emil
On 1/4/21 1:46 PM, Emil Velikov via pacman-dev wrote:
After a casual chat with some systemd and dbus devs - I was pointed at polkit. With polkit a) gaining and revoking root is trivial, b) it integrates nicely (better than gpg/pinentry) with tty, gnome, kde, etc, while it also c) provides for a consistent user experience.
"pinentry-program /usr/bin/pinentry-curses" integrates very nicely with the tty too, and is apropos for not context-switching between a terminal emulator running in a WM, and some popup window. I'm not aware of a similar option for polkit, it would likely defeat the purpose of most polkit uses though...
I'm not sure if you're joking or trolling here. I am aiming for "least privilege", moving from yaourt which absolutely sucks in that department, with pacman being a tiny bit better.
I don't see how yaourt is tied to principle of least privilege. Neither with yaourt, nor without yaourt, do you have principle of least privilege.
Last but not least, to reiterate pacman will work as original when the system lacks polkit all together.
No it won't... because you need to link to libpolkit-agent in order to support it, therefore it's a compile-time choice whether the "pacman" package depends on the "polkit" package. You could circumvent this by using exec(2) + /usr/bin/pkexec on the whole process, or if, like systemd, you *already* contain a dbus implementation that can send messages to org.freedesktop.PolicyKit1 without linking to polkit. -- Eli Schwartz Bug Wrangler and Trusted User
On Mon, 4 Jan 2021 at 20:12, Eli Schwartz via pacman-dev <pacman-dev@lists.archlinux.org> wrote:
On 1/4/21 1:46 PM, Emil Velikov via pacman-dev wrote:
After a casual chat with some systemd and dbus devs - I was pointed at polkit. With polkit a) gaining and revoking root is trivial, b) it integrates nicely (better than gpg/pinentry) with tty, gnome, kde, etc, while it also c) provides for a consistent user experience.
"pinentry-program /usr/bin/pinentry-curses" integrates very nicely with the tty too, and is apropos for not context-switching between a terminal emulator running in a WM, and some popup window.
pinentry fairly often chokes here, if GPG_TTY and the startup TTY aren't reset in just the right moment...
I'm not aware of a similar option for polkit, it would likely defeat the purpose of most polkit uses though...
... do agree though the explicit override pinentry-program is priceless.
I'm not sure if you're joking or trolling here. I am aiming for "least privilege", moving from yaourt which absolutely sucks in that department, with pacman being a tiny bit better.
I don't see how yaourt is tied to principle of least privilege. Neither with yaourt, nor without yaourt, do you have principle of least privilege.
Was trying to illustrate that yaourt is a step in the opposite direction - worst (yaourt) -> bad (pacman) -> good (polkit based pacman). Duly noted will not mention that helper again.
Last but not least, to reiterate pacman will work as original when the system lacks polkit all together.
No it won't... because you need to link to libpolkit-agent in order to support it, therefore it's a compile-time choice whether the "pacman" package depends on the "polkit" package.
Is dlopen/dlsym banned in pacman?
You could circumvent this by using exec(2) + /usr/bin/pkexec on the whole process, or if, like systemd, you *already* contain a dbus implementation that can send messages to org.freedesktop.PolicyKit1 without linking to polkit.
My initial idea was to try the systemd route and if implementation (or interdependencies) gets too messy - to fallback to pkexec. As you mentioned before separation is priority #1, elevation is 3+ Thanks Emil
So... I am super-anti polkit in any form for terminal based programs. I would be happy to use polkit in any graphical frontend, but we don't have one in the pacman code base! Lets break the problem down a bit: The areas we need root: a) package installation The areas we should run as a dedicated user: b) database download c) package download d) gpg verification (for keyring ownership) Am I missing anything? The rest can be run as a user. Currently, both the areas needing run as root and those that could be a dedicated user are well detected, so any operation requiring these at any stage checks for root privileges. Any operation not requiring root privileges at any stage can be run as a user. The problem is when there are combined operations! A "quick fix" would be to boot operations b-d to separate helper binaries, with the pacman binary offloading as necessary. That removes most of our attack space. For a more complete pacman fix, note that all root (or dedicated user) needed operations happen first in any transaction - e.g. -Syi does the "y" first, so pacman could just drop root privileges as soon as those are done. This is at the pacman level, so other libalpm frontends would need to re-invent the wheel. Which I think they mostly need to do anyway... We don't get a lot of feedback on what would help other frontends. Allan
WeOn January 5, 2021 1:43:32 AM GMT+01:00, Allan McRae via pacman-dev <pacman-dev@lists.archlinux.org> wrote:
So... I am super-anti polkit in any form for terminal based programs. I would be happy to use polkit in any graphical frontend, but we don't have one in the pacman code base!
Lets break the problem down a bit:
The areas we need root: a) package installation
The areas we should run as a dedicated user: b) database download c) package download d) gpg verification (for keyring ownership)
Am I missing anything?
The rest can be run as a user.
Currently, both the areas needing run as root and those that could be a dedicated user are well detected, so any operation requiring these at any stage checks for root privileges. Any operation not requiring root privileges at any stage can be run as a user. The problem is when there are combined operations!
A "quick fix" would be to boot operations b-d to separate helper binaries, with the pacman binary offloading as necessary. That removes most of our attack space.
For a more complete pacman fix, note that all root (or dedicated user) needed operations happen first in any transaction - e.g. -Syi does the "y" first, so pacman could just drop root privileges as soon as those are done.
So far so good, but I think it's a bit more complicated
On 5/1/21 12:14 pm, Levente Polyak via pacman-dev wrote:
WeOn January 5, 2021 1:43:32 AM GMT+01:00, Allan McRae via pacman-dev <pacman-dev@lists.archlinux.org> wrote:
So... I am super-anti polkit in any form for terminal based programs. I would be happy to use polkit in any graphical frontend, but we don't have one in the pacman code base!
Lets break the problem down a bit:
The areas we need root: a) package installation
The areas we should run as a dedicated user: b) database download c) package download d) gpg verification (for keyring ownership)
Am I missing anything?
The rest can be run as a user.
Currently, both the areas needing run as root and those that could be a dedicated user are well detected, so any operation requiring these at any stage checks for root privileges. Any operation not requiring root privileges at any stage can be run as a user. The problem is when there are combined operations!
A "quick fix" would be to boot operations b-d to separate helper binaries, with the pacman binary offloading as necessary. That removes most of our attack space.
For a more complete pacman fix, note that all root (or dedicated user) needed operations happen first in any transaction - e.g. -Syi does the "y" first, so pacman could just drop root privileges as soon as those are done.
So far so good, but I think it's a bit more complicated
Can you expand that thoughts rather than leaving us in a cloud of mystery?
On January 5, 2021 3:26:59 AM GMT+01:00, Allan McRae via pacman-dev <pacman-dev@lists.archlinux.org> wrote:
WeOn January 5, 2021 1:43:32 AM GMT+01:00, Allan McRae via pacman-dev <pacman-dev@lists.archlinux.org> wrote:
So... I am super-anti polkit in any form for terminal based
I would be happy to use polkit in any graphical frontend, but we don't have one in the pacman code base!
Lets break the problem down a bit:
The areas we need root: a) package installation
The areas we should run as a dedicated user: b) database download c) package download d) gpg verification (for keyring ownership)
Am I missing anything?
The rest can be run as a user.
Currently, both the areas needing run as root and those that could be a dedicated user are well detected, so any operation requiring these at any stage checks for root privileges. Any operation not requiring root privileges at any stage can be run as a user. The problem is when there are combined operations!
A "quick fix" would be to boot operations b-d to separate helper binaries, with the pacman binary offloading as necessary. That removes most of our attack space.
For a more complete pacman fix, note that all root (or dedicated user) needed operations happen first in any transaction - e.g. -Syi does
"y" first, so pacman could just drop root privileges as soon as
On 5/1/21 12:14 pm, Levente Polyak via pacman-dev wrote: programs. the those
are done.
So far so good, but I think it's a bit more complicated
Can you expand that thoughts rather than leaving us in a cloud of mystery?
Uff sorry this was a draft I started and needed to leave but instead the stupid MUA sent it. Guess I hit the wrong button. I agree with the first parts, but a simple sorted execution before dropping won't be sufficient, you will have separate user action before root privileged action for first syncing the database and downloading packages before installing them like a simple -Syu. There are multiple ways to achieve this, like with separated binary offloading or multiple forked execution with lower privileges. But it's certainly required to be able to execute lower privileged context before having a higher privileged context at the end like package installation. Even for a single action you want to have a non root context to download the packages. Cheers, Levente
On 1/4/21 9:45 PM, Levente Polyak via pacman-dev wrote:
I agree with the first parts, but a simple sorted execution before dropping won't be sufficient, you will have separate user action before root privileged action for first syncing the database and downloading packages before installing them like a simple -Syu.
There are multiple ways to achieve this, like with separated binary offloading or multiple forked execution with lower privileges. But it's certainly required to be able to execute lower privileged context before having a higher privileged context at the end like package installation. Even for a single action you want to have a non root context to download the packages.
As far as I can tell, the idea here is to: - run those dedicated tasks using e.g. separated binary offloading, - resume the main root flow for package installation, - then and only then consider the issue of "-Syi does not need root for the -i part", and then permanently, irrecoverably, drop permissions in order to do purely informational terminal output. -- Eli Schwartz Bug Wrangler and Trusted User
On 04-01-2021 19:46, Emil Velikov wrote:
On Mon, 4 Jan 2021 at 16:11, Maarten de Vries via pacman-dev <pacman-dev@lists.archlinux.org> wrote:
If you were to add restrictions on the allowed commands or require group membership, why not simply use custom sudo rules? You can configure sudo to allow certain commands without asking for a password if you really want to (but I wouldn't recommend that for pacman).
I'm aware of such sudo hacks, but that's all they are. Gruesome, do not scale and error prone (-Sy requires root, -Si foo does not, while -Syi foo is also a thing).
Well, gruesome is a personal opinion. Writing XML rules as polkit requires is something I myself find gruesome. But I agree, sudo rules are not a solution for everything. I was under the impression you wanted pacman to automatically obtain root privileges. In that case I do believe custom sudo rules are the simplest solution.
The opposite does sound nice: have pacman start as root and then drop privileges for parts of the code where it is not required.
There are more or less 3 pieces of software on my systems that use this approach - systemd (PID 1 so starts as root, although I doubt it drops priv), Xorg (prime example of new, well written and secure code) and OpenVPN (I think it no longer runs as root with last version)
To clear any ambiguity I was being sarcastic in the Xorg case. You are welcome to test how fragile the approach is (as implemented in Xorg) - it's close to impossible for the initial code (run as root) to attribute for each permutation, that will be triggered later on at runtime. So currently it drops permissions for a wide range of cases which actually require root.
After a casual chat with some systemd and dbus devs - I was pointed at polkit. With polkit a) gaining and revoking root is trivial, b) it integrates nicely (better than gpg/pinentry) with tty, gnome, kde, etc, while it also c) provides for a consistent user experience.
Right, so there is terrible software that does this. But there is also perfectly fine software that does this: opensmtpd, nginx and a plethora of other system services. I also find the user experience of sudo to be very consistent.
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. 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. If you just want `pacman` to automatically be `sudo pacman`, you can just add a shell alias or wrapper script in your $PATH :)
I'm not sure if you're joking or trolling here. I am aiming for "least privilege", moving from yaourt which absolutely sucks in that department, with pacman being a tiny bit better.
I am not joking or trolling. Please assume good faith, because my intentions are friendly. I have absolutely no intention of coming across as hostile. It is exactly your example of yaourt which led me to suggest an alias or script that just prefixes pacman with sudo. That seems to be what you're using yaourt for, but you seem to dislike yaourt. Simple solution: make a tiny wrapper that does only that bit. Anyway, Eli already commented with some more technical points. It's probably best to continue that thread of conversation. Regards, -- Maarten
On Mon, 4 Jan 2021 at 20:36, Maarten de Vries <maarten@de-vri.es> wrote:
On 04-01-2021 19:46, Emil Velikov wrote:
On Mon, 4 Jan 2021 at 16:11, Maarten de Vries via pacman-dev <pacman-dev@lists.archlinux.org> wrote:
If you were to add restrictions on the allowed commands or require group membership, why not simply use custom sudo rules? You can configure sudo to allow certain commands without asking for a password if you really want to (but I wouldn't recommend that for pacman).
I'm aware of such sudo hacks, but that's all they are. Gruesome, do not scale and error prone (-Sy requires root, -Si foo does not, while -Syi foo is also a thing).
Well, gruesome is a personal opinion. Writing XML rules as polkit requires is something I myself find gruesome.
But I agree, sudo rules are not a solution for everything. I was under the impression you wanted pacman to automatically obtain root privileges. In that case I do believe custom sudo rules are the simplest solution.
Fully agree - single sudo rule is the simplest, but from conceptual POV it does look like the worst option.
The opposite does sound nice: have pacman start as root and then drop privileges for parts of the code where it is not required.
There are more or less 3 pieces of software on my systems that use this approach - systemd (PID 1 so starts as root, although I doubt it drops priv), Xorg (prime example of new, well written and secure code) and OpenVPN (I think it no longer runs as root with last version)
To clear any ambiguity I was being sarcastic in the Xorg case. You are welcome to test how fragile the approach is (as implemented in Xorg) - it's close to impossible for the initial code (run as root) to attribute for each permutation, that will be triggered later on at runtime. So currently it drops permissions for a wide range of cases which actually require root.
After a casual chat with some systemd and dbus devs - I was pointed at polkit. With polkit a) gaining and revoking root is trivial, b) it integrates nicely (better than gpg/pinentry) with tty, gnome, kde, etc, while it also c) provides for a consistent user experience.
Right, so there is terrible software that does this. But there is also perfectly fine software that does this: opensmtpd, nginx and a plethora of other system services.
Interesting - will take a look into those as time permits.
I also find the user experience of sudo to be very consistent.
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. 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. If you just want `pacman` to automatically be `sudo pacman`, you can just add a shell alias or wrapper script in your $PATH :)
I'm not sure if you're joking or trolling here. I am aiming for "least privilege", moving from yaourt which absolutely sucks in that department, with pacman being a tiny bit better.
I am not joking or trolling. Please assume good faith, because my intentions are friendly. I have absolutely no intention of coming across as hostile.
There was nothing hostile in your suggestion - it read like a friendly troll so I wasn't really sure if you're serious.
It is exactly your example of yaourt which led me to suggest an alias or script that just prefixes pacman with sudo. That seems to be what you're using yaourt for, but you seem to dislike yaourt. Simple solution: make a tiny wrapper that does only that bit.
Yup, I'm yet again regretting ever mentioning yaourt - It definitely gave the wrong idea.
Anyway, Eli already commented with some more technical points. It's probably best to continue that thread of conversation.
Agreed. Thank you for the tips and ideas -Emil
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.
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,
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], ...) 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
On Mon, 4 Jan 2021 at 20:02, Eli Schwartz via pacman-dev <pacman-dev@lists.archlinux.org> wrote:
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".
You are spot on.
Then it prompts for root, most likely using a GUI dialog that grabs control of your entire screen.
AFAICT if there is a GUI agent installed and can be used it will. For example; having the gnome agent in a normal session - GUI. In a TTY or over SSH - the TTY agent will be displayed. In other words - it depends on what the user has installed and it's consistent with their overall experience. Wrt grabbing the entire screen - that depends on the agent implementation.
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.
The dbus part is spot on, although there was no JS engine last time I've looked.
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.
Whether there is a timeout (after a successful or failed attempt) is user configurable IIRC.
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.
I should not have mentioned yaourt, despite my love for yoghourt. The AUR functionality of it is a meh for me - that's why I did not mention it.
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...
One could detect the presence of sudo/pkexec early and opt for each/either one as you pointed out, finally bailing out as originally.
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 are 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...
This makes sense. IIRC other distributions are doing something similar.
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 "/".
Not entirely sold that starting as a root is a good idea. I've seen far too many horror stories while looking at Xorg. Will try and dig out some information how other package managers are handling it.
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], ...)
I was thinking of either `pkexec -u root pacman args` or `pkttyagent` with the smallest/simplest bus impl I could find.
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.
Ack. If I manage to pull it off I'll make sure that separation is handled as a minimum. Perhaps at that point you'll have a quick play around with the GUI/TTY handling - I've mentioned above. Thanks Emil
On 1/4/21 6:31 PM, Emil Velikov wrote:
On Mon, 4 Jan 2021 at 20:02, Eli Schwartz wrote:
Then it prompts for root, most likely using a GUI dialog that grabs control of your entire screen.
AFAICT if there is a GUI agent installed and can be used it will. For example; having the gnome agent in a normal session - GUI. In a TTY or over SSH - the TTY agent will be displayed.
In other words - it depends on what the user has installed and it's consistent with their overall experience.
Wrt grabbing the entire screen - that depends on the agent implementation.
Right, this is precisely the problem. There's no concept of "well, maybe the authentication needs of a CLI program are different from the needs of a GUI program", polkit agents merely care if you're booted into a display server or a tty. This is bad because user experiences should prefer "good" > "consistent". Trust me, I've experienced the polkit experience of $ pkexec bash ==== AUTHENTICATING FOR org.freedesktop.policykit.exec ==== Authentication is needed to run `/usr/bin/bash' as the super user Multiple identities can be used for authentication: 1. eschwartz [...] Choose identity to authenticate as (1-X): Unfortunately, the only way to get this "good" experience in a graphical terminal emulator running inside your WM, is to use an environment where you cannot get the GUI application menu or program windows to display the GUI polkit prompt they *should* have. :(
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.
The dbus part is spot on, although there was no JS engine last time I've looked.
polkit uses Mozilla Firefox's javascript engine to write and interpret polkit rules. It's part of the /usr/lib/polkit-1/polkitd daemon which you communicate with over the bus, not the part your application links to.
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.
Whether there is a timeout (after a successful or failed attempt) is user configurable IIRC.
This is unrelated to what I said? I merely drew a comparison between running `sudo pacman -Syu` and `pacman -Syu`, or running `sudo systemctl start ...` and `systemctl start ...`, that in each of the latter cases, you'd get an error message from pacman/systemctl itself, unless polkit avoids the error message by turning it into a "try to become root" prompt.
and exec() that for auto-retry-as-root. This then adds a hard dependency on sudo instead of polkit...
One could detect the presence of sudo/pkexec early and opt for each/either one as you pointed out, finally bailing out as originally.
Maybe if we permitted configuring the chosen tool of elevation in pacman.conf for the user's choice of sudo, su, pkexec, or doas. In fact, I have WIP code to do precisely this AUTH_CMD sort of setting in makepkg (which currently hardcodes sudo falling back to su in order to implement the run_pacman function used in makepkg -s, -i, -r options).
Not entirely sold that starting as a root is a good idea. I've seen far too many horror stories while looking at Xorg. Will try and dig out some information how other package managers are handling it.
"xorg is bad implementation, therefore every high-level, medium-level, and low-level goal it ever tries to do is bad even for clean-room implementations of similar concepts" is not an argument. In fact, let's go one step further: "xorg is bad, therefore something else is bad too" isn't an argument. If you want me to accept something is bad, you'll need to come up with a much better argument that has topical relevance and isn't based on random anecdotes from a program whose single overriding problem across the board is lots of instances of "the specific code implementation they used for XYZ is a bad coding style for doing XYZ". -- Eli Schwartz Bug Wrangler and Trusted User
On Tue, 5 Jan 2021 at 04:00, Eli Schwartz via pacman-dev <pacman-dev@lists.archlinux.org> wrote:
On 1/4/21 6:31 PM, Emil Velikov wrote:
On Mon, 4 Jan 2021 at 20:02, Eli Schwartz wrote:
Then it prompts for root, most likely using a GUI dialog that grabs control of your entire screen.
AFAICT if there is a GUI agent installed and can be used it will. For example; having the gnome agent in a normal session - GUI. In a TTY or over SSH - the TTY agent will be displayed.
In other words - it depends on what the user has installed and it's consistent with their overall experience.
Wrt grabbing the entire screen - that depends on the agent implementation.
Right, this is precisely the problem. There's no concept of "well, maybe the authentication needs of a CLI program are different from the needs of a GUI program", polkit agents merely care if you're booted into a display server or a tty.
This is bad because user experiences should prefer "good" > "consistent".
Trust me, I've experienced the polkit experience of
$ pkexec bash ==== AUTHENTICATING FOR org.freedesktop.policykit.exec ==== Authentication is needed to run `/usr/bin/bash' as the super user Multiple identities can be used for authentication: 1. eschwartz [...] Choose identity to authenticate as (1-X):
Unfortunately, the only way to get this "good" experience in a graphical terminal emulator running inside your WM, is to use an environment where you cannot get the GUI application menu or program windows to display the GUI polkit prompt they *should* have. :(
I see what's happening - personally the polkit CLI experience is perfectly reasonable. Seems like I'm a minority.
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.
The dbus part is spot on, although there was no JS engine last time I've looked.
polkit uses Mozilla Firefox's javascript engine to write and interpret polkit rules. It's part of the /usr/lib/polkit-1/polkitd daemon which you communicate with over the bus, not the part your application links to.
You're spot on. There was a proposal to switch to lua some 5+ years ago and seemingly that never happened.
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.
Whether there is a timeout (after a successful or failed attempt) is user configurable IIRC.
This is unrelated to what I said? I merely drew a comparison between running `sudo pacman -Syu` and `pacman -Syu`, or running `sudo systemctl start ...` and `systemctl start ...`, that in each of the latter cases, you'd get an error message from pacman/systemctl itself, unless polkit avoids the error message by turning it into a "try to become root" prompt.
I see - my bad.
and exec() that for auto-retry-as-root. This then adds a hard dependency on sudo instead of polkit...
One could detect the presence of sudo/pkexec early and opt for each/either one as you pointed out, finally bailing out as originally.
Maybe if we permitted configuring the chosen tool of elevation in pacman.conf for the user's choice of sudo, su, pkexec, or doas.
In fact, I have WIP code to do precisely this AUTH_CMD sort of setting in makepkg (which currently hardcodes sudo falling back to su in order to implement the run_pacman function used in makepkg -s, -i, -r options).
Such would be perfect IMHO.
Not entirely sold that starting as a root is a good idea. I've seen far too many horror stories while looking at Xorg. Will try and dig out some information how other package managers are handling it.
"xorg is bad implementation, therefore every high-level, medium-level, and low-level goal it ever tries to do is bad even for clean-room implementations of similar concepts" is not an argument.
In fact, let's go one step further: "xorg is bad, therefore something else is bad too" isn't an argument. If you want me to accept something is bad, you'll need to come up with a much better argument that has topical relevance and isn't based on random anecdotes from a program whose single overriding problem across the board is lots of instances of "the specific code implementation they used for XYZ is a bad coding style for doing XYZ".
I'm not claiming that every solution is bad because I saw one which has bugs. Merely pointing out that the combinatorial explosion and hence complexity required is much greater with the single binary using "start as root" approach. And with greater complexity - a greater probability for bugs etc. Huge thanks to everyone for the input in this thread. I did not expect it to be as popular :-) Thanks Emil
participants (5)
-
Allan McRae
-
Eli Schwartz
-
Emil Velikov
-
Levente Polyak
-
Maarten de Vries