Polkitd + KDE Plasma on Kubuntu 20.04 - Possible to emulate local behaviour?

[alexhorner]

Hello,

I bring another polkitd related issue I'm afraid. I have looked at #1773 and #1889 and skimmed through some others,

I have seen mentions of .conf files not working with polkitd anymore which is something I have tried without success, so that seems likely in my scenario too.

This issue is present with both XRDP and X2Go, both of which I wish to use but am struggling due to this issue.

#1773 seems to focus very much on fixing singular popup issues, however this isn't what I want to do. My machine is fully headless, and everything works perfectly when I connect a display, mouse and keyboard, but when using it headless I get varying quantities of authentication popups named Authentication Required - PolicyKit1 KDE Agent regarding network controls and at various other points on the system.

The WiFi toggle and controls do not work, shutdown and restart do not work.

If at all possible, I would like to have XRDP (and X2Go, however understandably this is not for you to worry about) log into the system with the exact same policies applied as would be applied logging into a local display on the system. I do understand the security implications of doing such a thing, however seeing as this machine is intended to run fully headless I think this is an acceptable thing to do.

I understand this is probably not the most detailed issue, however I am really struggling to bring together the components of other issues here to get this to work as I intend, and the amount of information online is lacking with regards to actual fixes, just full of single popup removals and various workarounds for single scenarios, not something more generic. I am of course more than happy to provide any additional context requested.

[matt335672]

Hi @alexhorner

If at all possible, I would like to have XRDP (and X2Go, however understandably this is not for you to worry about) log into the system with the exact same policies applied as would be applied logging into a local display on the system.

I can see where you're coming from, but as far as we can tell, this simply isn't possible.

Depending on your distribution, you will need to set up ini-based pkla files (polkit <=0 0.105) or Javascript-based ones (polkit > 0.105). In both of these, actions can be wildcarded in order to increase their scope - this can make it easier to limit the number of files required.

At the moment, that's the best I can give you, I'm afraid.

[alexhorner]

Hi @matt335672,

I can see where you're coming from, but as far as we can tell, this simply isn't possible.

Ah that's a real shame. I thought it might be possible to find and copy and adapt the rules defined for the local display.

Depending on your distribution, you will need to set up ini-based pkla files (polkit <=0 0.105) or Javascript-based ones (polkit > 0.105). In both of these, actions can be wildcarded in order to increase their scope - this can make it easier to limit the number of files required.

I had considered experimenting with a blanket wildcard, but as with any permissions system, it is indeed possible to give yourself too many permissions resulting in undefined or undesired consequences, which is something I am concerned about in doing this.

I would imagine my only alternative is to try and find some way to find each permission for each broken element of the system and slowly build a list of corrections.

Any advice would be much appreciated though I understand this is a tricky subject with caveats and oddities in all directions. Thanks!

[matt335672]

You can use pkaction to list all the action IDs, and pkaction --verbose --action-id=<whatever> to see how they are set up. In theory you could script this to generate required pkla files. It's perfectly doable. Downsides:-

1. This would affect other remote sessions, like ssh sessions.
2. It's a bit brittle.

[alexhorner]

You can use pkaction to list all the action IDs, and pkaction --verbose --action-id=<whatever> to see how they are set up. In theory you could script this to generate required pkla files. It's perfectly doable. Downsides:-

1. This would affect other remote sessions, like ssh sessions.
2. It's a bit brittle.

I don't think polkitd would affect a terminal based session would it? Just X11 forwarding, which I don't use anyway.

I see what you mean by using pkaction but do you know if I can sort of point at a thing that's broken and get the action ID? I'm assuming if I put polkitd into som kind of verbose mode I could see this logged somewhere.

[matt335672]

polkitd affects everything - not just GUI sessions. Try systemctl restart xrdp from a ssh prompt for an unprivileged user, and you'll see it in action (at least you do on Ubuntu 20.04).

Getting the action ID can be the trickiest part of this, as different desktops present it in different ways. If you cancel a request operation this will generally get logged somewhere, like /var/log/auth or in the systemd journal. Alternatively you can restart polkitd in debugging mode. We did this in #1889, but you may be able to do it on the command line. This seems to work for me (again, on Ubuntu 20.04):-

sudo G_MESSAGES_DEBUG=all /usr/lib/policykit-1/polkitd -r

[alexhorner]

polkitd affects everything - not just GUI sessions. Try systemctl restart xrdp from a ssh prompt for an unprivileged user, and you'll see it in action (at least you do on Ubuntu 20.04).

Getting the action ID can be the trickiest part of this, as different desktops present it in different ways. If you cancel a request operation this will generally get logged somewhere, like /var/log/auth or in the systemd journal. Alternatively you can restart polkitd in debugging mode. We did this in #1889, but you may be able to do it on the command line. This seems to work for me (again, on Ubuntu 20.04):-

sudo G_MESSAGES_DEBUG=all /usr/lib/policykit-1/polkitd -r

Awesome, thanks for the advice. I'll give this a try later and report back

[alexhorner]

Hi there,

So my Kubuntu 20.04 install uses PKLA files. I feel like my understanding of this is getting better, and I think I am beginning to understand why you said

I can see where you're coming from, but as far as we can tell, this simply isn't possible.

as there doesn't appear to be any INI option you can set when local=0 even when active=1

I have successfully used your debug command to view what I was looking for with regards to what gets triggered for these popups and the system tray controls. It does indeed state that I am not authorised to access these functions when coming in from a remote connection. When coming in from a local display, I am authorised with the message is authorized (has implicit authorization local=1 active=1) which I assume means the local=1 gives me implicit authorisation to the associated functions without prompt for credentials/identity proof.

I feel like if the distro came with a newer PolkitD which supported the JavaScript based rules, I might be in with a chance of working out some rules which permit the same things remotely as are permitted locally.

I have considered again doing the wildcard on literally everything to blanket permit me everything, however as I have said before I do not know the consequences of doing this, as there are a few things which are not authorised (related to backlight control for example) even when connected via a local display. I would have assumed this is because it is a desktop system without a backlight but I would say that knowledge is nothing to do with PolkitD therefore this is not the reason for not being authorised, and here stems the fear of unintended consequences if I were to do a blanket permit.

It would be awesome if this issue could be kept open for now, for I am eager to post any solutions, workarounds and findings I may find, and it would also be nice to see someone else having success that they can post here too.

For now I am no further along, however I do feel I have a better understanding of the complexities of PolkitD.

[matt335672]

Hi @alexhorner

As regards the Javascript, don't expect that in Ubuntu/Debian any time soon. Polkit 0.106 was released in June 2012. Debian continues to stick with the old style from 0.105. See this discussion for more info.

The local=1 active=1 maps to the implicit active field returned by pkaction. On the system I'm currently on (Mint Una), pkaction --verbose --action-id org.freedesktop.login1.reboot gives me:-

$ pkaction --action-id org.freedesktop.login1.reboot
org.freedesktop.login1.reboot
mjb@andelain:~/Desktop$ pkaction --verbose --action-id org.freedesktop.login1.reboot
org.freedesktop.login1.reboot:
  description:       Reboot the system
  message:           Authentication is required to reboot the system.
  vendor:            The systemd Project
  vendor_url:        http://www.freedesktop.org/wiki/Software/systemd
  icon:              
  implicit any:      auth_admin_keep
  implicit inactive: auth_admin_keep
  implicit active:   yes
  annotation:        org.freedesktop.policykit.imply -> org.freedesktop.login1.set-wall-message

Consequently, the reboot command without sudo works fine from the command line on a native terminal. I just verified that by rebooting my machine halfway though writing this (In my defence I need a coffee!) On the other hand, if I ssh localhost as the same user, and try reboot, the command fails:-

$ reboot
Failed to set wall message, ignoring: Interactive authentication required.
Failed to reboot system via logind: Interactive authentication required.
Failed to open initctl fifo: Permission denied
Failed to talk to init daemon.

If you want to get a decent rule set to start with, you could maybe work on a local session for a bit with polkit logging enabled, and then parse the resulting log file to see what actions are implicitly authorized while you're in the session.

I'll convert this issue to a discussion, as this is the best place for keeping things in the long-term.

[alexhorner]

I think the speed at which Linux usually restarts makes the coffee break quite reasonable!

I just read that post you included, interesting to see that it was just updated 3 hours ago at time of writing.

The idea of parsing a long running log whilst using a local session certainly seems like a sensible way to deal with this for now. I need to learn the PKLA format better to produce an output for it I think, but I don't think that will be much trouble considering it's just INI. Worst case scenario I could present a CSV or something and someone with more expertise can produce the rules I suppose.

Is there any way I can contribute something back to XRDP? I'm most certainly more than happy to provide a configuration which contains all the rules I have produced if I go ahead with a parse, and of course I'll have to keep it somewhat up to date with distro updates.

Thanks for converting this to a discussion by the way!

[matt335672]

Contributing to the discussion is a great way to contribute to xrdp. polkit has a bit of a learning curve, and most people who post issues which are polkit related don't even know it exists.

[rcfa]

I have essentially the same issue (RasPi with iPadPro as "console").
How does the local=1 get determined?
Is there a way to start xrdp where that is set to 1? Or in other words: where/what/when/who sets that property to one for a given session?

[alexhorner]

I do believe this is not possible to change and is managed at a deeper level than all of this, however I do not know the specifics.

I am pretty sure this will go nowhere unfortunately, however I would certainly be interested in the technicalities of this in general.

I have been meaning to write a script to parse that PolkitD log output so I can build rules for remote connections, but I haven't got round to it yet.

[rcfa]

Well, yes, that's the issue. I can't find any useful documentation.

Obviously polkit can't be compiled with a pre-set set of programs that are considered "local".

An X-Client or window manager isn't more local than xrdp, just by itself.

So there must be some mechanism, which I can't seem to find documentation on, by means of which "locality" is defined. It might well be, that it might require a custom build of xrdp, or something; but at this point I'd just like to discover the mechanism.

Google so far wasn't a useful friend...

[alexhorner]

I have vague mutterings in my head of recollection of there being certain flags one can set when running commands to determine a user login session to be local or not but it is something I don't recall

[akarl10]

if the local information is coming from systemd session type "console", then a session is local if it is bound to a VT (that is /dev/tty). Not really adequate for xrdp

[alexhorner]

So, just today, I have decided that writing a Python script for this task is out of my reasonable work ability, and have proceeded to install Debian 11 + KDE instead of Kubuntu 20.04. If someone wants to take that task on that would be cool, but to me it just seems like a lot of effort for a timewaster problem which shouldn't exist anyway.

However, upon my installation and start of Debian 11 + KDE - Well what do you know, Polkit 0.105 here too. Same issues here too:

I need to look further into whether this can be upgraded to 0.106, but I am not hopeful because all the rules will need to be rewritten. This basically, to my knowledge, knocks out both of the .deb/apt capable (for lack of a better definition of Debian/Ubuntu derivatives) distros that have KDE. I don't know if that makes KDE the support problem or what.

At a bit of a loss with how to progress for now. Frustrated but searching will continue.

[akarl10]

I am currently packaging xrdp in my own ubuntu ppa (not the upstream version but an egfx enabled branch)

Since I was there, I "fixed" this kind of issues by creating a system group (called xrdp-session) that gets added with pam_group to xrdp sessions only (wonder why noone came to that idea)
This gives me the possibility to make polkit rules that check the availability of that group and lets me get around that annoying requests without opening the whole system.

about KDE and xrdp: let me tell you that gnome is not better supported here. instead of this dialog you get one asking for color setup. on ubuntu by default the gnome desktop launches instead of the ubuntu gnome desktop.

[akarl10]

ok, further testing reviled that I was crashing polkitd with a js rule in ubuntu (looks like it does not support those). Still, on ubutnu you can put something like

[Xrdp desktop permissions]
Identity=*
Action=org.freedesktop.NetworkManager.network-control;org.freedesktop.NetworkManager.wifi.scan;org.freedesktop.color-manager.*
ResultAny=no

in /etc/polkit-1/localauthority/50-local.d/01-xrdp.pkla

of course you can narrow down acces by putting something like
Identity=unix-group:users
instead and then consider ResultAny=yes and ResultInactive=yes

[alexhorner]

ok, further testing reviled that I was crashing polkitd with a js rule in ubuntu (looks like it does not support those). Still, on ubutnu you can put something like

[Xrdp desktop permissions]
Identity=*
Action=org.freedesktop.NetworkManager.network-control;org.freedesktop.NetworkManager.wifi.scan;org.freedesktop.color-manager.*
ResultAny=no

in /etc/polkit-1/localauthority/50-local.d/01-xrdp.pkla

of course you can narrow down acces by putting something like
Identity=unix-group:users
instead and then consider ResultAny=yes and ResultInactive=yes

Correct, the whole problem is that we're using an older version of Polkit pretty much everywhere which doesn't support JS rules. If JS rules were supported, this probably wouldn't be an issue

[alexhorner]

ok, further testing reviled that I was crashing polkitd with a js rule in ubuntu (looks like it does not support those). Still, on ubutnu you can put something like

[Xrdp desktop permissions]
Identity=*
Action=org.freedesktop.NetworkManager.network-control;org.freedesktop.NetworkManager.wifi.scan;org.freedesktop.color-manager.*
ResultAny=no

in /etc/polkit-1/localauthority/50-local.d/01-xrdp.pkla

of course you can narrow down acces by putting something like
Identity=unix-group:users
instead and then consider ResultAny=yes and ResultInactive=yes

Correct, the whole problem is that we're using an older version of Polkit pretty much everywhere which doesn't support JS rules. If JS rules were supported, this probably wouldn't be an issue

Just to expand a little too, there's too many broken things to be able to manually list each required rule one by one. This is why I spoke of potentially making a Python script above. Such a python script would read the Polkit log to see denied requests and automatically build a rules file with all the rules set.

I have found this is a task which I wouldn't want to undertake because its incredibly hacky and will likely cause further problems if it includes a rule we don't want, and also we shouldn't have to build hacky workarounds like this when the correct solution would be a Polkit update.

The Polkit version is managed by the distro maintainers though, and it's not a simple transition from the older version to the newer version. All existing rules would need to be rewritten.

Both Debian and Ubuntu use the old version from what I have tested so both those distros, and their derivatives, are a no-go for this kind of use case.

[akarl10]

In theory the polkit action list is finite.
quick not so human readable list is
grep id=\" /usr/share/polkit-1/actions/*

for the most of them the default makes sense imho. The annoying thing are password requests immediatly after login.
This is why I set ResultAny=no in my example: I don't want to be able to change network settings if I am remote.
You could add a second rule that allows this for sudo users.

Still, having a newer polkit would granted me to make a rule that uses polkit.spawn to ask a script/application/whatever that checks if the calling pid/application is in fact a xrdp launched one (using either the pam_group "mark" mentioned above or simply by traversing the process tree) and if there is a match respond with yes or no (or auth if that makes sense, for example reboot over a remote connection), but you get the idea.

[alexhorner]

I think I can now basically confirm this to be a Debian scoped issue and not a KDE Plasma scoped issue.

I installed another 2 installs of Debian 11, from scratch to make it as clean as possible, and one time I chose XRDP and the other I chose Cinnamon. Both of these DEs experienced the exact same popups for the exact same reasons, triggered by Polkit.

[alexhorner]

So I may or may not have an update on this. I am not familiar with Debian Experimental at all, but it appears polkit has been updated to 0.116 in Debian Experimental.

It is still 0.105 in Debian Sid, though, so I do not know if this means the next Sid will be taken from Experimental therefore the next Sid will include 0.116. If someone is more familiar with this, I'd love to know

https://packages.debian.org/experimental/libpolkit-gobject-1-0

Edit: Okay it seems I am good at missing things!

Bullseye seems to be using 0.105: https://packages.debian.org/source/bullseye/policykit-1
Sid seems to be using 122?: https://packages.debian.org/source/sid/policykit-1

[issuefiler]

Having the same issue with fresh-installed Debian Bookworm (testing-stage) and KDE Plasma 5.26.90, connected through an xorgxrdp connection.
This pops up every time I start a new empty session.

[issuefiler]

This appears every time I use apt, too.

[matt335672]

It's the same issue.

If you want your users to be able to do this, you can add a polkit rule to let them. If you don't want them to, don't add the rule, or add a rule forbidding them.

We can't decide what the system management policy should be, as part of this product.

[issuefiler]

Wrote a Javascript Polkit .rules file for the user and the pop-up does not appear any more! I can mount USBs, too. Thank you.

[alexhorner]

Wrote a Javascript Polkit .rules file for the user and the pop-up does not appear any more! I can mount USBs, too. Thank you.

Hi @issuefiler

What distro are you using? I can't find any decent distro using the newer version of polkit that allows this, they all use the older version with the limited special format.

Thanks!

[matt335672]

Anyone following this thread may be interested in this debugging aid I've put together for Polkit:-

https://github.com/matt335672/pk-local

[alexhorner]

Hey @matt335672

Thanks for putting this aid together! I think if we were all on a version newer than 0.105, this would be less of an issue. The problem is the fact distros will just not move on. Its extremely infuriating.

I would guess if we were on this later version, we could craft javascript rules which specifically give remote users the same privileges as local ones (or even override what the system thinks the user really is) however I am not certain of this (maybe this is exactly what your script does? I have not yet looked at it properly), considering no distro I actually want to use has bothered to update to a later version of polkit yet.

I shall take a proper read of your script later and play with it too and get back to you on how it's going.

[matt335672]

Debian Bookworm looks to be moving away from 0.105, so things may finally be changing in this regard.

Realistically, you can't change what sort of user the system thinks you are. The best you can do is use rules/pkla.

I'm hoping it's pretty obvious what the script does. Comments welcome.

[alexhorner]

Debian Bookworm looks to be moving away from 0.105, so things may finally be changing in this regard.

Realistically, you can't change what sort of user the system thinks you are. The best you can do is use rules/pkla.

I'm hoping it's pretty obvious what the script does. Comments welcome.

I have tested your script and I can confirm it indeed works as intended!

I think I have a pretty good idea of what you're doing in the script, however I am not particularly good at reading bash scripts.

Having looked at the output generated, I can see at the very least it is finding all of the possible rules and overriding them with the original value and a new value which is derived from the original value.

I'm aware that the implications of these rules can be hard to explain, but I have one main question regarding them - Do these rules bring permissions inline with a local user, or do they actually surpass the normal capabilities of a local user?

You do of course warn not to use these rules on an internet connected system, but if appropriate precautions are put in place (definitely not directly exposing RDP to the world) this should be fine to do, just like with root access via SSH.

[matt335672]

All the script is doing is allowing users in the pk-local group to have the same Polkit-granted privileges they would do as if sat at the console.

What it's doing is easy to understand. The implications are not:-

• Badly designed Polkit actions could well come with unintended consequences.
• When looking at CVE ratings, bear in mind part of the rating process is whether the CVE is actionable over a network or via a local user. If you've run this script, you're making the scope of any vulnerability potentially far worse.

Security is, of course, a process. When making any modifications to a system which potentially affect its security, it's important to look at the system as a whole when trying to decide if making the modification is justified.

An example of where using this script with no thought would be a very bad idea is running it on a host inside a corporate firewall with no other protections. A bad actor who gets limited access to your corporate network might now able to use a vulnerability in your system to completely compromise it, and potentially other parts of the corporate network.

If your system is only accessible over a personal VPN you may decide that opening up some parts of it for convenience is justified. That's entirely up to you of course, but before doing so, make sure you've done your homework.