cannot use pkexec

[AnonymousUser]

Need to install a policykit authentication agent .

Please try.

But in the Whonix 15 there is already this file:

/etc/xdg/autostart/polkit-gnome-authentication-agent-1.desktop

containing this line:

Exec=/usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1

Is that not a ‘policykit authentication agent’?

Also need to decide which package would be the most suitable one. Criteria unknown.

OK. To simplify it, for now, can we therefore make it ZuluCrypt.

Again and again I import the Whonix 15 OVA (and I’ve checked its hash to make sure not corrupt), and before doing anything else (after initial wizard), I click on ZuluCrypt from the Whisker Menu and it simply gives that polkit error I’ve provided in the screenshot.

Can you reproduce this? The answer to that question will guide us where to go next.

[madaidan]

pkexec seems to be a fancy su which won’t work when the root account is locked.

• Synaptic (try launching it from Whisker Menu) - first install via apt install synaptic
• KDE Partition Manager (install via sudo apt-get install partitionmanager ) - it normally is supposed to launch with an admin password prompt.
• Thunderbird , possibly (haven’t tested). It always prompts with GUI password box when you want to cache your PGP key for the rest of the session. This would be broken due to the same principle as GDebi being broken.
• Opera , possibly. Tends to do a GUI password prompt upon launch.

You don’t seem to realise that not every single password prompt is now broken. Only ones using su to switch to the root user are and if those applications are doing that, you can make a bug report to get them to switch to sudo.

Can you reproduce this?

I can reproduce it.

[AnonymousUser]

You don’t seem to realise that not every single password prompt is now broken. Only ones using su to switch to the root user are and if those applications are doing that, you can make a bug report to get them to switch to sudo .

OK, so to fix this problem recently introduced into Whonix 15 that affects a rather core part of the Debian GUI experience that most of us have used for years, we can either:

• Request upstream developers for dozens of famous packages used by vastly more people than in the Whonix community to change a long-standing element of how every one of their packages work, and if we’re lucky, wait 1-3 years for it to trickle down to Debian stable repo.

or

• Fix Whonix at our own pace right now. (Very quick, appreciate that.)

There are probably hundreds of well-known packages that use root in the way that Whonix 15 right now has broken.

Of course, I’m with you here, who doesn’t like more security? I’m still interested in Qubes development, even though I’ve chosen amnesic Debian as my host OS security instead.

But we can’t break the universal user experience like this.

So what are we going to do?

[Patrick_mobile]

It will be fixed. Relax.There is no need for extended debate on priorities without contributing to solutions.

[madaidan]

Fix Whonix at our own pace right now.

and suffer a big security decrease…

As pointed out in use sudoedit in Whonix documentation

https://help.ubuntu.com/community/RootSudo says

even pkexec is being deprecated by the mainline Ubuntu developers

Probably won’t be long before Debian deprecates it too.

[Patrick_mobile]

As use sudoedit in Whonix documentation says, I’ve read conflicting information about the fate of pkexec. Citation required.

[AnonymousUser]

It will be fixed. Relax.There is no need for extended debate on priorities without contributing to solutions.

Thanks @Patrick.

In this situation, I’d ideally hope a solution was found to achieve both needs here. But I wouldn’t want that to delay fixing what I see as a more urgent problem (for basic pkexec to work again, a famous and fundamental part of current Debian). That bug should be rolled back first, then an ‘ideal’ fix researched after that.

Also, you can’t ask users who report bugs to always provide the solutions for them. We all have our place, and reporters can be very helpful.

[Patrick]

As pointed out in use sudoedit in Whonix documentation

https://help.ubuntu.com/community/RootSudo says

even pkexec is being deprecated by the mainline Ubuntu developers

Probably won’t be long before Debian deprecates it too.

use sudoedit in Whonix documentation

Very much citation required since https://help.ubuntu.com/community/RootSudo also says: March 14, 2019 PLEASE NOTE: This wiki article is being significanly rewritten as it contains a good deal of old, dated and possibly questionable material. Using caution and consulting with others on the Ubuntu Forums or Ask Ubuntu is highly recommended!

[Patrick]

dpkg -S `which pkexec`

policykit-1: /usr/bin/pkexec

Quote https://wiki.debian.org/PolicyKit

While PolicyKit has been replaced by polkit (which rewrote system component, breaking backwards compatibility) in many distributions, Debian continues to use PolicyKit from wheezy through to buster.

Polkit

Quote

Since version 0.105, released in April 2012,[2][3] the name of the project was changed[ by whom? ] from PolicyKit to polkit to emphasize that the system component was rewritten[4] and that the API had changed, breaking backward compatibility.[5][ dubious – discuss ]

Fedora became the first distribution to include PolicyKit, and it has since been used in other distributions, including Ubuntu since version 8.04 and openSUSE since version 10.3. Some distributions, like Fedora,[6] have already switched to the rewritten polkit.

Quote https://tracker.debian.org/pkg/policykit-1

• Debian version: 0.105-26
• [2019-08-11] Accepted policykit-1 0.116-2 (source) into experimental (Simon McVittie)

This is also interesting because at the moment packages by Whonix use lxsudo. Maybe bullseye based Whonix should be ported to use polkit.

[AnonymousUser]

@Patrick Thanks for starting to look into it.

I have found another major feature of XFCE that is also broken due due to the current whonix mod:

When you attach a VDI in VirtualBox to your Whonix-Workstation (as a way to easily expand your storage), you can no longer mount it via GUI in Thunar.

A hard disk item in Thunar appears under Devices (e.g. ‘200 GB Volume’), and when clicking on it, a GUI password prompt should appear to mount it, but nothing does in the current Whonix 15 OVA.

You have to turn off password security in the Thunar and/or UDisks2 policykit files in order to get it to work.

[Patrick]

Could try this workaround. It replaces pkexec with lxsudo. That might fix all applications.

sudo cp /usr/bin/pkexec /usr/bin/pkexec.backup
sudo rm /usr/bin/pkexec
sudo ln -s /usr/bin/lxsudo /usr/bin/pkexec

[madaidan]

thunar-volman is disabled by default anyway.

Whonix/security-misc/blob/master/etc/skel/.config/xfce4/xfconf/xfce-perchannel-xml/thunar.xml

[Patrick]

thunar volman discussion also here:

Whonix XFCE Development

Algernon: Currently enabling or disabling does nothing since Thunar-Volman is not installed and you would also need to enable auomounting manually. It’s more like a 49 vs 51% decision. So let’s not change it. I’d even consider installing Thunar-Volman by default. Depends on the kind of backdoor or malware and people actually looking for such files. There are certainly better and more complex ways to hide files. The usability impact probably depends on personal preferences. Let’s keep …

possibly related:

cannot access encrypted USB drive with Thunar in Whonix 15

I posted this issue on http://forums.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/t/whonix-virtualbox-15-0-0-4-9-point-release/8076 but this thread is probably the right place for this. Assuming it is permissions, I tried to run Thunar from the command line and got the same results as expected. Then, I tried lxsudo Thunar but that doesn’t show the USB drive.

[AnonymousUser]

Could try this workaround. It replaces pkexec with lxsudo. That might fix all applications.

sudo cp /usr/bin/pkexec /usr/bin/pkexec.backup
sudo rm /usr/bin/pkexec
sudo ln -s /usr/bin/lxsudo /usr/bin/pkexec

That doesn’t fix it. On a fresh Whonix-XFCE-15.0.0.4.9.ova, after doing those 3 commands:

Launching ZuluCrypt still doesn’t work, produces a pop-up:

lxqt-sudo: no backend chosen!

I click OK and then the same ZuluCrypt polkit error as before pops up.

Tried Synaptic as another test: same lxqt-sudo: no backend chosen! error.

[Patrick_mobile]

Try delete the symlink and use pkexec being a wrapper script calling lxsudo instead.

[Patrick]

That might not have worked since lxsudo itself is just a symlink to lxqt-sudo.

Try delete the symlink and use pkexec being a wrapper script calling lxsudo instead.

Instructions:

sudo unlink /usr/bin/pkexec
sudo rm /usr/bin/pkexec
sudoedit /usr/bin/pkexec

contents of wrapper /usr/bin/pkexec:

#!/bin/bash
/usr/bin/lxqt-sudo "$@"

Save.

Make executable.

sudo chmod +x /usr/bin/pkexec

Try.

[AnonymousUser]

@Patrick OK I have tried the above.

It does make ZuluCryppt, Synaptic, and KDE Partition Manager (after you add pkexec to the .desktop Exec= command line) work.

However, mounting a vbox-added virtual hard drive in Thunar still doesn’t work. (only my very insecure .policy hack makes it work.)

So those commands aren’t a full fix - yet.

Happy to keep trying more instructions you provide.

[Patrick]

Correcting my previous post.

Wrong:

contents of wrapper /usr/bin/lxqt-sudo :

Edited, fixed:

contents of wrapper /usr/bin/pkexec :

I guess you had that right already?

(after you add pkexec to the .desktop Exec= command line)

I am surprised. No, I didn’t suppose editing .desktop Exec= files would be required. It looked plausible to me that replacing pkexec with lxqt-sudo should fix all applications which use Exec= pkexec (already default, no user modification) something or within their wrapper script.

[AnonymousUser]

@Patrick No, my .desktop mod only has to apply to KDE Partition Manager. (I’ve needed to do it ever since moving to XFCE from KDE Whonix. To me it is superior to / easier to use than GParted, even though it comes from KDE.) I just mentioned that detail to be more complete. Also, for what it’s worth, your previous instructions were incompatible with my own fix for Thunar disk mounting (UDisks2 .policy file).

I’ll have to try your corrected instructions another time soon, will report back.

[amoretpax]

I am also experiencing issues starting Zulucrypt (the only application so far for me) with the error relating to pkexec. I applied the (edited) fix posted above, and the application starts, but exits with “unknown error status 255” when I try to mount a volume (in a file) previously created and opened using Zulucrypt in Whonix before the problem manifested. It might not be related (though it is curious timing if not), but wanted to convey my experience. Thanks for working on a solution.