[pacman-dev] Adding privilege levitation to pacman

[Emil Velikov]

On Mon, 4 Jan 2021 at 20:36, Maarten de Vries <maarten at 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 at 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