F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/polkit_recommends_pkla_pkexec


== Summary ==
Split `pkexec` from the polkit package and make it a recommended only
sub-package. Similarly, make the polkit-pkla-compat package a
recommended package too. This will enable users and desktop no longer
relying on those features to avoid installing them.

== Owner ==
* Name: [[User:Siosm| Timothée Ravier]], Jan Rybar
* Email: siosm(a)fedoraproject.org, jrybar(a)redhat.com


== Detailed Description ==

`pkexec` and `pkla-compat`
([https://src.fedoraproject.org/rpms/polkit-pkla-compat package]) are
legacy tools that are no longer needed on a desktop and increase the
attack surface as they are SetUID binaries (`pkexec`) or not
maintained anymore (`pkla-compat`).

This change will thus split `pkexec` from the polkit package and make
it a recommended only sub-package. Similarly, it will make the
polkit-pkla-compat package a recommended package too. This will enable
users and desktop no longer relying on those features to avoid
installing them. Users that still need those features will easily be
able to install them.

See in progress PR: https://src.fedoraproject.org/rpms/polkit/pull-request/2

== Feedback ==

Related discussion in
https://lists.fedoraproject.org/archives/list/[e-mail].o...

See in progress PR: https://src.fedoraproject.org/rpms/polkit/pull-request/2

== Benefit to Fedora ==

Increased security, less legacy software installed by default, moving
to a more secure desktop by default.

== Scope ==
* Proposal owners:
** Test as many desktop environments as possible and add the new
dependencies for the packages requiring either polkit-pkla-compat
rules support or pkexec.

* Other developers:
** Test as many desktop environments as possible and add the new
dependencies for the packages requiring either polkit-pkla-compat
rules support or pkexec.

* Release engineering:
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A
* Alignment with Objectives:


== Upgrade/compatibility impact ==

Nothing should happen during upgrades for existing systems as the
packages are still available and will be kept as is and the new
polkit-pkexec package will be installed for users not deselecting
recommends.

Only new installations that will not have those packages will be
impacted and the risk of security issues with the pkla rules removal
is low.

== How To Test ==

1. Install the polkit package from
https://copr.fedorainfracloud.org/coprs/siosm/polkit/
2. Remove the polkit-pkexec sub-package and polkit-pkla-compat package
3. Ensure that your applications and desktop environment are still
working as intended. Focus on applications that require privileges.

== User Experience ==

N/A

== Dependencies ==

N/A

== Contingency Plan ==

Revert the change.

== Documentation ==

N/A (not a System Wide Change)

== Release Notes ==

TODO



-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis

[Adam Williamson]

On Wed, 2022-02-16 at 12:12 -0500, Ben Cotton wrote:
>  https://fedoraproject.org/wiki/Changes/polkit_recommends_pkla_pkexec
>  
>  
>  == Summary ==
>  Split `pkexec` from the polkit package and make it a recommended only
>  sub-package. Similarly, make the polkit-pkla-compat package a
>  recommended package too. This will enable users and desktop no longer
>  relying on those features to avoid installing them. 
Splitting them off but making them Recommended seems odd to me. At that
point we've got all the work of splitting them but little of the
benefit, because soft dependencies are included when building images,
so our default installs are still going to include pkexec.

Why not just not have them recommended at all, and instead try to find
all packages that use them and add dependencies, so that they will be
included when an image or whatever really does need them? Is that
considered too difficult?

Thanks!
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Timothée Ravier]

>  Splitting them off but making them Recommended seems odd to me. At
> that
>  point we've got all the work of splitting them but little of the
>  benefit, because soft dependencies are included when building images,
>  so our default installs are still going to include pkexec.
>  
>  Why not just not have them recommended at all, and instead try to find
>  all packages that use them and add dependencies, so that they will be
>  included when an image or whatever really does need them? Is that
>  considered too difficult? 
I went with Recommends to be conservative. We could indeed make them fully optional if we
end up being confident we will not break the default user experience.

--
Timothée Ravier
CoreOS engineer & Fedora Kinoite maintainer

[James Szinger]

On Wed, 16 Feb 2022 09:17:41 -0800
Adam Williamson <adamwill(a)fedoraproject.org&gt; wrote:

>  On Wed, 2022-02-16 at 12:12 -0500, Ben Cotton wrote:
>  > https://fedoraproject.org/wiki/Changes/polkit_recommends_pkla_pkexec
>  > 
>  > == Summary ==
>  > Split `pkexec` from the polkit package and make it a recommended
>  > only sub-package. Similarly, make the polkit-pkla-compat package a
>  > recommended package too. This will enable users and desktop no
>  > longer relying on those features to avoid installing them.  
>  
>  Splitting them off but making them Recommended seems odd to me. At
>  that point we've got all the work of splitting them but little of the
>  benefit, because soft dependencies are included when building images,
>  so our default installs are still going to include pkexec.
>  
>  Why not just not have them recommended at all, and instead try to find
>  all packages that use them and add dependencies, so that they will be
>  included when an image or whatever really does need them? Is that
>  considered too difficult? 
I woould prefer having hard dependencies on the necessary packages
instead of a recommends.  Some of us run with weak dependencies turned
off and the missing requires will break things for us.  Having the
recommends in place will mask the breakage instead of letting it be
caught in testing.

Jim

[Lennart Poettering]

On Mi, 16.02.22 12:12, Ben Cotton (bcotton(a)redhat.com) wrote:

>  `pkexec` and `pkla-compat`
>  ([https://src.fedoraproject.org/rpms/polkit-pkla-compat package]) are
>  legacy tools that are no longer needed on a desktop and increase the
>  attack surface as they are SetUID binaries (`pkexec`) or not
>  maintained anymore (`pkla-compat`). 
I find this wording weird... I seriously doubt we should consider
"pkexec" legacy. It's the much nicer approach to the "sudo"
problem,
as mentioned in earlier discussions...

Splitting it off into a separate package might be OK, but claiming
that the fact that it is a suid binary makes it "legacy" sounds really
strange to me, by that means we should also mark "sudo", "su",
"ping",
"mount", "umount", "write", "passwd", … and so on
"legacy", but I
doubt we are at that point, are we?

hence I am not against the feature but please tone down the wording
regarding pkexec, it's misleading. Say you want to split it out to
reduce the attack surface, but don't use the word "legacy" in its
context.

(dropping "pkla-compat" given its unmaintained state is Ok to be
called "legacy" i guess)

Lennart

--
Lennart Poettering, Berlin

[Timothée Ravier]

>  I find this wording weird... I seriously doubt we should consider
>  "pkexec" legacy. It's the much nicer approach to the "sudo"
>  problem,
>  as mentioned in earlier discussions...
>  
>  Splitting it off into a separate package might be OK, but claiming
>  that the fact that it is a suid binary makes it "legacy" sounds really
>  strange to me, by that means we should also mark "sudo", "su",
>  "ping",
>  "mount", "umount", "write", "passwd", … and so
> on
>  "legacy", but I
>  doubt we are at that point, are we?
>  
>  hence I am not against the feature but please tone down the wording
>  regarding pkexec, it's misleading. Say you want to split it out to
>  reduce the attack surface, but don't use the word "legacy" in its
>  context.
>  
>  (dropping "pkla-compat" given its unmaintained state is Ok to be
>  called "legacy" i guess) 
I agree that the wording is stronger than it should be. I'll update that.

--
Timothée Ravier
CoreOS engineer & Fedora Kinoite maintainer

[Neal Gompa]

On Wed, Feb 16, 2022 at 12:38 PM Lennart Poettering
<mzerqung(a)0pointer.de&gt; wrote:
>  On Mi, 16.02.22 12:12, Ben Cotton (bcotton(a)redhat.com) wrote:
>
>  > `pkexec` and `pkla-compat`
>  > ([https://src.fedoraproject.org/rpms/polkit-pkla-compat package]) are
>  > legacy tools that are no longer needed on a desktop and increase the
>  > attack surface as they are SetUID binaries (`pkexec`) or not
>  > maintained anymore (`pkla-compat`).
>
>  I find this wording weird... I seriously doubt we should consider
>  "pkexec" legacy. It's the much nicer approach to the "sudo"
> problem,
>  as mentioned in earlier discussions...
>
>  Splitting it off into a separate package might be OK, but claiming
>  that the fact that it is a suid binary makes it "legacy" sounds really
>  strange to me, by that means we should also mark "sudo", "su",
> "ping",
>  "mount", "umount", "write", "passwd", … and so on
> "legacy", but I
>  doubt we are at that point, are we?
>
>  hence I am not against the feature but please tone down the wording
>  regarding pkexec, it's misleading. Say you want to split it out to
>  reduce the attack surface, but don't use the word "legacy" in its
>  context.
>
>  (dropping "pkla-compat" given its unmaintained state is Ok to be
>  called "legacy" i guess)
>  
I think I'd go stronger and say I don't really see the value in
splitting out pkexec at all. I'd rather people have a default path to
do safer privilege escalation, and pkexec is way better than
sudo/doas/etc in that regard.


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Adam Williamson]

On Wed, 2022-02-16 at 13:55 -0500, Neal Gompa wrote:
>  On Wed, Feb 16, 2022 at 12:38 PM Lennart Poettering
>  <mzerqung(a)0pointer.de&gt; wrote:
>  > 
>  > On Mi, 16.02.22 12:12, Ben Cotton (bcotton(a)redhat.com) wrote:
>  > 
>  > > `pkexec` and `pkla-compat`
>  > > ([https://src.fedoraproject.org/rpms/polkit-pkla-compat package]) are
>  > > legacy tools that are no longer needed on a desktop and increase the
>  > > attack surface as they are SetUID binaries (`pkexec`) or not
>  > > maintained anymore (`pkla-compat`).
>  > 
>  > I find this wording weird... I seriously doubt we should consider
>  > "pkexec" legacy. It's the much nicer approach to the "sudo"
> problem,
>  > as mentioned in earlier discussions...
>  > 
>  > Splitting it off into a separate package might be OK, but claiming
>  > that the fact that it is a suid binary makes it "legacy" sounds really
>  > strange to me, by that means we should also mark "sudo", "su",
> "ping",
>  > "mount", "umount", "write", "passwd", … and
> so on "legacy", but I
>  > doubt we are at that point, are we?
>  > 
>  > hence I am not against the feature but please tone down the wording
>  > regarding pkexec, it's misleading. Say you want to split it out to
>  > reduce the attack surface, but don't use the word "legacy" in its
>  > context.
>  > 
>  > (dropping "pkla-compat" given its unmaintained state is Ok to be
>  > called "legacy" i guess)
>  > 
>  
>  I think I'd go stronger and say I don't really see the value in
>  splitting out pkexec at all. I'd rather people have a default path to
>  do safer privilege escalation, and pkexec is way better than
>  sudo/doas/etc in that regard. 
This feels a bit unrealistic to me. In the real world, I can recall off
the top of my head exactly zero docs, guides, articles, howtos etc.
that use pkexec. They all use sudo. Like it or not, sudo is what people
use. The sensible thing to do there is devote attention to making sure
sudo is as secure as possible, or actually make some kind of big effort
to convince people to use pkexec instead.

But just shipping pkexec as well as sudo by default is IMHO not helping
anything, all it does is add unnecessary attack surface. I bet you
could shoulder-surf for an entire weekend at Flock and not see a single
person type 'pkexec'.

I just tried this, actually, for giggles. Two reasons it's a non-
starter: it prompts for the root password, not for my user password (my
user is an 'admin' so far as sudo etc. are concerned, but apparently
not an 'admin' so far as interactive pkexec is concerned). I do not
know the root password, it is intentionally a 24-character random
string I would have to look up. And it prompts with one of those
goddamn 'secure' GNOME popovers which prevents you accessing your
password manager, so every time you hit one, you have to cancel it, go
to your password manager, copy the password it wants, then trigger it
again.

No way on earth I'm using that.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Owen Taylor]

On Thu, Feb 17, 2022 at 2:28 PM Adam Williamson <adamwill(a)fedoraproject.org&gt;
wrote:

>  On Wed, 2022-02-16 at 13:55 -0500, Neal Gompa wrote:
>  > On Wed, Feb 16, 2022 at 12:38 PM Lennart Poettering
>  > <mzerqung(a)0pointer.de&gt; wrote:
>  > >
>  > > On Mi, 16.02.22 12:12, Ben Cotton (bcotton(a)redhat.com) wrote:
>  > >
>  > > > `pkexec` and `pkla-compat`
>  > > > ([https://src.fedoraproject.org/rpms/polkit-pkla-compat package])
>  are
>  > > > legacy tools that are no longer needed on a desktop and increase the
>  > > > attack surface as they are SetUID binaries (`pkexec`) or not
>  > > > maintained anymore (`pkla-compat`).
>  > >
>  > > I find this wording weird... I seriously doubt we should consider
>  > > "pkexec" legacy. It's the much nicer approach to the
> "sudo" problem,
>  > > as mentioned in earlier discussions...
>  > >
>  > > Splitting it off into a separate package might be OK, but claiming
>  > > that the fact that it is a suid binary makes it "legacy" sounds
> really
>  > > strange to me, by that means we should also mark "sudo",
> "su", "ping",
>  > > "mount", "umount", "write", "passwd", …
> and so on "legacy", but I
>  > > doubt we are at that point, are we?
>  > >
>  > > hence I am not against the feature but please tone down the wording
>  > > regarding pkexec, it's misleading. Say you want to split it out to
>  > > reduce the attack surface, but don't use the word "legacy" in
> its
>  > > context.
>  > >
>  > > (dropping "pkla-compat" given its unmaintained state is Ok to be
>  > > called "legacy" i guess)
>  > >
>  >
>  > I think I'd go stronger and say I don't really see the value in
>  > splitting out pkexec at all. I'd rather people have a default path to
>  > do safer privilege escalation, and pkexec is way better than
>  > sudo/doas/etc in that regard.
>
>  This feels a bit unrealistic to me. In the real world, I can recall off
>  the top of my head exactly zero docs, guides, articles, howtos etc.
>  that use pkexec. They all use sudo. Like it or not, sudo is what people
>  use. The sensible thing to do there is devote attention to making sure
>  sudo is as secure as possible, or actually make some kind of big effort
>  to convince people to use pkexec instead.
>
>  But just shipping pkexec as well as sudo by default is IMHO not helping
>  anything, all it does is add unnecessary attack surface. I bet you
>  could shoulder-surf for an entire weekend at Flock and not see a single
>  person type 'pkexec'.
>  
Perhaps it actually works well that pkexec is used for "behind-the-scenes"
privilege escalation, and sudo is what people are familiar with for
interactive and sysadmin-configured use. PolKit and hence pkexec can make
decisions on things that sudo doesn't have an idea about like the idea of
"logged in at a graphical console", but they aren't really useful if you
just want to quickly run a command as root with authentication.

I just tried this, actually, for giggles. Two reasons it's a non-
>  starter: it prompts for the root password, not for my user password
> (my
>  user is an 'admin' so far as sudo etc. are concerned, but apparently
>  not an 'admin' so far as interactive pkexec is concerned). I do not
>  know the root password, it is intentionally a 24-character random
>  string I would have to look up. And it prompts with one of those
>  goddamn 'secure' GNOME popovers which prevents you accessing your
>  password manager, so every time you hit one, you have to cancel it, go
>  to your password manager, copy the password it wants, then trigger it
>  again.
>  
I think you misinterpreted the prompt. Assuming your user is in the wheel
group:

 "Authentication is needed to run '<x>' as the superuser'

Isn't asking for the root password, but rather your password to do
something as root.

- Owen

[Adam Williamson]

On Thu, 2022-02-17 at 15:29 -0500, Owen Taylor wrote:
>  
>  I just tried this, actually, for giggles. Two reasons it's a non-
>  > starter: it prompts for the root password, not for my user password (my
>  > user is an 'admin' so far as sudo etc. are concerned, but apparently
>  > not an 'admin' so far as interactive pkexec is concerned). I do not
>  > know the root password, it is intentionally a 24-character random
>  > string I would have to look up. And it prompts with one of those
>  > goddamn 'secure' GNOME popovers which prevents you accessing your
>  > password manager, so every time you hit one, you have to cancel it, go
>  > to your password manager, copy the password it wants, then trigger it
>  > again.
>  > 
>  
>  I think you misinterpreted the prompt. Assuming your user is in the wheel
>  group:
>  
>   "Authentication is needed to run '<x>' as the superuser'
>  
>  Isn't asking for the root password, but rather your password to do
>  something as root. 
Nope. The name shown was "Administrator" (which means it wants the root
password), and entering my user password does not work. Entering the
root password does.

This may not be the case for everyone, but hey, I just did a quick test
on my desktop, and that's what I found.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Garry T. Williams]

On Wednesday, February 16, 2022 6:01:48 PM EST Adam Williamson wrote:
>  I just tried this, actually, for giggles. Two reasons it's a
> non-
>  starter: it prompts for the root password, not for my user password
>  (my user is an 'admin' so far as sudo etc. are concerned, but
>  apparently not an 'admin' so far as interactive pkexec is
>  concerned). 
That is odd.  I am never prompted for the root password for anything.
Maybe this is a policy difference between GNOME and KDE.

My supplemental groups:

    wheel mock systemd-journal wireshark

>  I do not know the root password, it is intentionally a
>  24-character random string I would have to look up. And it prompts
>  with one of those goddamn 'secure' GNOME popovers which prevents you
>  accessing your password manager, so every time you hit one, you have
>  to cancel it, go to your password manager, copy the password it
>  wants, then trigger it again.
>
>  No way on earth I'm using that. 
Again, in KDE, there is a prompt for MY password and it is only modal
as far as the pkexec command is concerned.  I can open my password
manager before responding to the prompt (not that I need to, since it
wants my password -- not root's).

Anyway, until this discussion, I never knew there was a pkexec.  I
note that pkexec will not operate correctly outside of my KDE session.
It prompts for my password from a terminal session and then fails with

    $ pkexec ls
    ==== AUTHENTICATING FOR org.freedesktop.policykit.exec ====
    Authentication is needed to run `/usr/bin/ls' as the super user
    Authenticating as: Garry T. Williams (garry)
    Password:
    polkit-agent-helper-1: error response to PolicyKit daemon:
GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
    ==== AUTHENTICATION FAILED ====
    Error executing command as another user: Not authorized

    This incident has been reported.
    $

Of course, sudo will operate correctly without a desktop session.  I
don't think I will be eager to use pkexec instead of sudo.

-- 
Garry T. Williams

[Lennart Poettering]

On Mi, 16.02.22 15:01, Adam Williamson (adamwill(a)fedoraproject.org) wrote:

>  > > hence I am not against the feature but please tone down the
> wording
>  > > regarding pkexec, it's misleading. Say you want to split it out to
>  > > reduce the attack surface, but don't use the word "legacy" in
> its
>  > > context.
>  > >
>  > > (dropping "pkla-compat" given its unmaintained state is Ok to be
>  > > called "legacy" i guess)
>  >
>  > I think I'd go stronger and say I don't really see the value in
>  > splitting out pkexec at all. I'd rather people have a default path to
>  > do safer privilege escalation, and pkexec is way better than
>  > sudo/doas/etc in that regard.
>
>  This feels a bit unrealistic to me. In the real world, I can recall off
>  the top of my head exactly zero docs, guides, articles, howtos etc.
>  that use pkexec. They all use sudo. Like it or not, sudo is what people
>  use. The sensible thing to do there is devote attention to making sure
>  sudo is as secure as possible, or actually make some kind of big effort
>  to convince people to use pkexec instead. 
sudo is what users/admins use. pkexec is what (desktop) programs often use.

docs/guides/articles/howtos are focussed on users/admins. hence of
course, you won't find it mentioned there.

>  I just tried this, actually, for giggles. Two reasons it's a
> non-
>  starter: it prompts for the root password, not for my user password (my
>  user is an 'admin' so far as sudo etc. are concerned, but apparently
>  not an 'admin' so far as interactive pkexec is concerned). I do not
>  know the root password, it is intentionally a 24-character random
>  string I would have to look up. 
When I hit "pkexec" a nice GNOME shell prompt pops up asking me for
*my* password, not root's.

>  And it prompts with one of those
>  goddamn 'secure' GNOME popovers which prevents you accessing your
>  password manager, so every time you hit one, you have to cancel it, go
>  to your password manager, copy the password it wants, then trigger it
>  again.
>
>  No way on earth I'm using that. 
Then don't. But whether you use it or whether it's "legacy"/should go
away are two distinct questions.

Lennart

--
Lennart Poettering, Berlin

[Adam Williamson]

On Fri, 2022-02-18 at 13:54 +0100, Lennart Poettering wrote:
>  
>  sudo is what users/admins use. pkexec is what (desktop) programs often use. 
In which case we can have the programs that use it depend on it, so at
least we have those requirements mapped distinctly. To me it makes more
sense to say "let's install pkexec when we are also installing
something that uses it" than "let's install pkexec any time we install
polkit".

>  Then don't. But whether you use it or whether it's
> "legacy"/should go
>  away are two distinct questions. 
I agree, but your argument read to me like "we must keep it installed
even when no program that uses it is installed, for interactive use",
which I disagree with.

I think focusing on the word "legacy" misses the point. The real meat
of the idea for me is "let's only install it when it's needed", which I
think would be good.

Still, if it's as tied in to Workstation as it seems to be, the effort
may not be worthwhile. We'd only ultimately be able to drop it, maybe,
from minimal and Server installs. If it still has to be in KDE and
Workstation installs, the value of doing all the work to separate it
and find all the packages that use it may not be worthwhile.
-- 
Adam Williamson
Fedora QA
IRC: adamw | Twitter: adamw_ha
https://www.happyassassin.net

[Zbigniew Jędrzejewski-Szmek]

>  https://fedoraproject.org/wiki/Changes/polkit_recommends_pkla_pkexec
>  See in progress PR:
> https://src.fedoraproject.org/rpms/polkit/pull-request/2 
From a comment in the PR:
>  IMHO making polkit-pkla-compat optional is seriously risky. The
>  configuration can contain “if user=foo deny” entries, and silently
>  ignoring those configuration files can break the security of the
>  system. 
If polkit indeed treats rules it doesn't have currently support for
as always satisfied, I would treat this is a blocker for splitting
out polkit-pkla-compat.

Zbyszek

[Owen Taylor]

On Wed, Feb 16, 2022 at 12:14 PM Ben Cotton <bcotton(a)redhat.com&gt; wrote:

>  https://fedoraproject.org/wiki/Changes/polkit_recommends_pkla_pkexec
>  [..]
>  `pkexec` and `pkla-compat`
>  ([https://src.fedoraproject.org/rpms/polkit-pkla-compat package]) are
>  legacy tools that are no longer needed on a desktop and increase the
>  attack surface as they are SetUID binaries (`pkexec`) or not
>  maintained anymore (`pkla-compat`). 

For pkexec, "no longer needed on a desktop" definitely does not reflect the
situation for Fedora Workstation and GNOME. If you run:

 grep org.freedesktop.policykit.exec.path /usr/share/polkit-1/actions/*

there is considerable usage - there are config files using pkexec provided
by, among others:

 gamemode, fedora-third-party, systemd, gnome-control-center,
gnome-system-monitor, gnome-settings-daemon, gvfs,

Would it be possible to rewrite all of the usage as D-Bus services? Yes -
but it would be considerable work and risk of new bugs and regressions.
(fedora-third-party is a recent addition by me - I considered not using
pkexec and writing a service instead, but it seemed like extra work and
complexity for little gain.)

If KDE or another desktop doesn't use pkexec, and there's a desire to split
pkexec out in packaging and add explicit dependencies on it, I'm not
opposed to that, but I don't think we should be calling pkexec legacy, and
it would require considerable (upstream, not just Fedora) changes to remove
the usage in Workstation.

- Owen