Bug 1171115 - sddm: org.freedesktop.login1.* in restrictive profile: KDE hangs on logout when choosing "shut down"
sddm: org.freedesktop.login1.* in restrictive profile: KDE hangs on logout wh...
Status: NEW
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Security
Current
Other Other
: P5 - None : Normal (vote)
: ---
Assigned To: Fabian Vogt
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2020-05-04 17:08 UTC by Christian Boltz
Modified: 2020-10-08 10:51 UTC (History)
4 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Boltz 2020-05-04 17:08:22 UTC
PERMISSION_SECURITY="secure local" in /etc/sysconfig/security works for most things even in desktop usage, but KDE hangs on logout when choosing "shut down" (german "Herunterfahren").

The fix for this are the following two entries in /etc/polkit-default-privs.local:

org.freedesktop.login1.power-off   auth_admin_keep:auth_admin_keep:yes
org.freedesktop.login1.reboot      auth_admin_keep:auth_admin_keep:yes

After running /sbin/set_polkit_default_privs I can shut down my computer from the KDE logout dialog again.

Please consider to add these two for polkit-default-privs.restrictive.
(Without these two lines, the workaround is to logout, and then shutdown from sddm ;-)


Sidenotes:
- The default in restrictive is "auth_admin_keep", and I guess it's too late 
  in the logout process to show a password dialog, so the logout simply hangs.
- The only other local rules I need to live with "permissions.secure" are
  org.freedesktop.packagekit.system-sources-refresh
                                           auth_admin_keep_always:no:yes
  org.freedesktop.NetworkManager.network-control               no:no:yes
  # mount / umount USB stick
  org.freedesktop.udisks2.filesystem-mount     auth_admin:auth_admin:yes
  org.freedesktop.udisks2.eject-media          auth_admin:auth_admin:yes
Comment 1 Matthias Gerstner 2020-05-05 08:38:55 UTC
Hello and thank you for opening a bug report.

Actually this behaviour is only indirectly related to PERMISSION_SECURITY. The
problem originates in polkit-default-privs which are switched to "restrictive"
in case PERMISSIONS_SECURITY contains "secure" and POLKIT_DEFAULT_PRIVS is
unset.

What exactly happens when you're trying to shut down? Is the graphical
session locked up?

The problem with these polkit settings is that upstream never tests any
settings diverging from their own defaults. So actually KDE would need to
support this use case by displaying an authentication prompt or obtain
authorization some other way.

Apart from that it is open for debate whether it is useful to deny locally
logged in users to reboot or shutdown a system even in the restrictive polkit
setting. I guess denying that is a rather special use case for kiosk systems
or similar situations.

Regarding system-sources-refresh: This setting is about to be relaxed in
Tumbleweed already so this should not be a problem starting with on of the
next Tumbleweed snapshots.

I'd say that network-control and mount/umount actions are restricted is
intentional for the "restrictive" polkit profile. You can always override
individual settings using the "local" polkit profile in
/etc/polkit-default-privs.local.

Actually the security would like to better differentiate between system roles
like "workstation", "multiuser system" and "server". This would allow to
provide better defaults. This would require deep rooting changes in the
distribution, however, that aren't easy to implement.
Comment 2 Christian Boltz 2020-05-05 10:39:46 UTC
(In reply to Matthias Gerstner from comment #1)
> What exactly happens when you're trying to shut down? Is the graphical
> session locked up?

All running programs including the task bar get closed, and the desktop goes black. In the end, I have a black screen with working mouse pointer - and Ctrl-Alt-Backspace seems to be the only option to kill the session.

> Apart from that it is open for debate whether it is useful to deny locally
> logged in users to reboot or shutdown a system even in the restrictive polkit
> setting. I guess denying that is a rather special use case for kiosk systems
> or similar situations.

As I already mentioned - after logging out, I can shutdown or reboot the system from sddm (without entering a password) which makes denying that to KDE a bit funny ;-)

> I'd say that network-control and mount/umount actions are restricted is
> intentional for the "restrictive" polkit profile. You can always override
> individual settings using the "local" polkit profile in
> /etc/polkit-default-privs.local.

No problem - I mentioned these things "for completeness", and fully understand that there are reasons to have them restricted in secure mode.

> Actually the security would like to better differentiate between system roles
> like "workstation", "multiuser system" and "server". This would allow to
> provide better defaults. This would require deep rooting changes in the
> distribution, however, that aren't easy to implement.

To make it even more complicated - how would you categorize my laptop?
Right now, I'm logged in in KDE - and in the background I have Apache, MySQL etc. running ;-)

I'm afraid the only sane (and at the same time easy-to-implement) option is to handle this as a manual setting, for example
    PERMISSION_SECURITY="secure desktop local"
(IMHO "secure" could include the server bits, and "desktop" could be used to relax some things like allowing to mount USB sticks.)
Comment 3 Matthias Gerstner 2020-05-06 10:16:03 UTC
(In reply to suse-beta@cboltz.de from comment #2)
> 
> All running programs including the task bar get closed, and the desktop goes
> black. In the end, I have a black screen with working mouse pointer - and
> Ctrl-Alt-Backspace seems to be the only option to kill the session.

okay I try to reproduce and if I can confirm that I'll reassign this bug to
our KDE maintainers, because this should also be fixed upstream.

> As I already mentioned - after logging out, I can shutdown or reboot the
> system from sddm (without entering a password) which makes denying that to
> KDE a bit funny ;-)

I know.

> To make it even more complicated - how would you categorize my laptop?

Probably a single-user desktop.

> Right now, I'm logged in in KDE - and in the background I have Apache, MySQL
> etc. running ;-)

This sounds like a power user scenario so I can expect of you to customize
settings to your liking :-)

I think we will also relax the power-off and reboot actions for locally logged
in users in the restrictive polkit profile. I'm still discussing this.
Comment 4 Matthias Gerstner 2020-05-06 11:28:31 UTC
I was able to reproduce the issue. KDE Plasma behaves strange when trying to
reboot or shtudown when the respective polkit action is on auth_*.

The problem roots deeper than the power-off and reboot polkit actions,
however. The following set of actions is available:

org.freedesktop.login1.power-off
org.freedesktop.login1.reboot
org.freedesktop.login1.hibernate
org.freedesktop.login1.suspend
org.freedesktop.login1.halt

org.freedesktop.login1.power-off-multiple-sessions
org.freedesktop.login1.reboot-multiple-sessions
org.freedesktop.login1.hibernate-multiple-sessions
org.freedesktop.login1.suspend-multiple-sessions
org.freedesktop.login1.halt-multiple-sessions

I think we can relax the single-session actions. The mutiple-sessions actions
should not be relaxed, however, because this would allow any local user to
quit other local or remote user sessions. Furthermore KDE Plasma also behaves
badly the same way when multiple sessions are open and the multiple-sessions
action is on auth_*.

There is definitely some bug in KDE that needs to be fixed.
Comment 5 Matthias Gerstner 2020-05-06 11:31:07 UTC
I'm adding the bugowner of kded to the bug. This problem should definitely be
reported to upstream. Can you please take care of that?
Comment 6 Fabian Vogt 2020-05-06 11:49:10 UTC
I assume this happens because polkit-kde-authentication-agent-1 is killed before the poweroff request is sent and the auth triggered.

Can you run "killall polkit-kde-authentication-agent-1; /usr/lib64/libexec/polkit-kde-authentication-agent-1 &; disown" before attempting a shut down? That should not get killed early and confirm the theory.
Comment 7 Matthias Gerstner 2020-05-06 12:15:46 UTC
(In reply to fabian@ritter-vogt.de from comment #6)
> Can you run "killall polkit-kde-authentication-agent-1;
> /usr/lib64/libexec/polkit-kde-authentication-agent-1 &; disown" before
> attempting a shut down? That should not get killed early and confirm the
> theory.

It does get killed. However I can't tell whether is getting killed "too
early".

Actually nothing should be killed, before the action is authorized. If the
authorization fails then there is nothing to shutdown or reboot.
Comment 8 Fabian Vogt 2020-05-06 12:26:00 UTC
(In reply to Matthias Gerstner from comment #7)
> (In reply to fabian@ritter-vogt.de from comment #6)
> > Can you run "killall polkit-kde-authentication-agent-1;
> > /usr/lib64/libexec/polkit-kde-authentication-agent-1 &; disown" before
> > attempting a shut down? That should not get killed early and confirm the
> > theory.
> 
> It does get killed. However I can't tell whether is getting killed "too
> early".
> 
> Actually nothing should be killed, before the action is authorized. If the
> authorization fails then there is nothing to shutdown or reboot.

The Plasma session management is currently undergoing a rewrite anyway, this might be one of the planned changes.
Comment 9 Matthias Gerstner 2020-05-07 07:44:53 UTC
(In reply to fabian@ritter-vogt.de from comment #8)
> The Plasma session management is currently undergoing a rewrite anyway, this
> might be one of the planned changes.

So are you reporting this to upstream now, or are we just hoping that things
will fix themselves?
Comment 10 Fabian Vogt 2020-05-07 07:53:21 UTC
(In reply to Matthias Gerstner from comment #9)
> (In reply to fabian@ritter-vogt.de from comment #8)
> > The Plasma session management is currently undergoing a rewrite anyway, this
> > might be one of the planned changes.
> 
> So are you reporting this to upstream now, or are we just hoping that things
> will fix themselves?

I asked upstream whether this is being done already and if not I'll report it.
Comment 11 Fabian Vogt 2020-05-07 14:36:44 UTC
(In reply to Fabian Vogt from comment #10)
> (In reply to Matthias Gerstner from comment #9)
> > (In reply to fabian@ritter-vogt.de from comment #8)
> > > The Plasma session management is currently undergoing a rewrite anyway, this
> > > might be one of the planned changes.
> > 
> > So are you reporting this to upstream now, or are we just hoping that things
> > will fix themselves?
> 
> I asked upstream whether this is being done already and if not I'll report
> it.

Had a quick discussion.

"Save yourself and exit" is currently a single step, which can also cause the power action to be cancelled. That's why it runs before the dbus call is made. There is currently work going on to improve this situation in general by adding a  feature (a new QCoreApplication attribute) to Qt.
Comment 12 Matthias Gerstner 2020-05-08 08:47:17 UTC
Okay so the general lockup issue is in KDE upstream's court then.

I'll talk with the rest of the security team next week about the loosening of
the polkit actions. It's a bit of a strange corner, because the display
managers always allow shutdown/reboot without password entry. So having it
restricted in polkit is useless.
Comment 13 Ludwig Nussel 2020-05-11 12:21:42 UTC
So far requiring admin authentication for reboot or shutdown has been an explicit SLE requirement. So this bug has to be fixed in KDE and not by hiding it with relaxed permissions.
If the displaymanagers you tested don't ask for authentication then that's a bug as well.
Comment 14 Matthias Gerstner 2020-05-11 12:59:56 UTC
(In reply to lnussel@suse.com from comment #13)
> So far requiring admin authentication for reboot or shutdown has been an
> explicit SLE requirement.

Can you point us to where this requirement has been defined?

> So this bug has to be fixed in KDE and not by hiding it with relaxed
> permissions.

We never intended to fix a KDE bug via polkit privileges.

> If the displaymanagers you tested don't ask for authentication then that's a
> bug as well.

Yes, Malte is going to investigate this with systemd-logind upstream.

But there other possiblities for a local user to shutdown or reboot:

- switching to text mode and pressing ctrl-alt-del will reboot.
- pressing the power / reset button will shutdown / reboot, the hard way if
  necessary.

Also hibernate and suspend are currently allowed for local users in the polkit
restrictive profile.
Comment 15 Ludwig Nussel 2020-05-11 13:57:51 UTC
I'm sure it buried in some old fate, bug discussion or changelogs of displaymanagers. I remember having the same concerns wrt ctrl-alt-del or simply pulling the power plug. That however was not considered critical for the use case. Feel free to talk to PM about their current view on the topic as even SLE 15 is still consistent with previous behavior.

Note that by applying your arguments for allowing shutdown and reboot there is no reason to not apply the same policy also for the multiple-sessions privileges.
Comment 16 Matthias Gerstner 2020-05-12 07:56:11 UTC
(In reply to lnussel@suse.com from comment #15)
> I remember having the same concerns wrt ctrl-alt-del or simply pulling the
> power plug. That however was not considered critical for the use case.

That would mean that it is not about security but about something else. And
therefore would be a misuse of Polkit altogether IMO.

> Note that by applying your arguments for allowing shutdown and reboot there
> is no reason to not apply the same policy also for the multiple-sessions
> privileges.

One reason might be to misuse Polkit for something else than security, namely
a kind of "warning" that there are other sessions around ;-)

I will check back with the team and PM. I personally don't care about one way
or the other but I'd like to have coherent settings and documentation about
why things are as they are.
Comment 17 Matthias Gerstner 2020-10-08 10:51:18 UTC
So Malte looked into display managers a couple of months ago and not all of
them ignore the polkit settings so it makes sense to have them this way in the
restrictive profile. I won't make any changes to the existing actions.

I'm reassigning this to fvogt to check whether the bug is actually fixed on
the KDE side by now. Downgrading this from an AUDIT to a regular maintenance
bug.