cannot use pkexec

Support
21

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

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.

1 Like
22

@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.

23

Correcting my previous post.

Wrong:

Edited, fixed:

I guess you had that right already?

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.

1 Like
24

@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.

25

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.

1 Like
26

@Patrick thanks for the updated instructions.

Results:

  • ZuluCrypt launches, and I think @amoretpax’s problem is probably unrelated to this pkexec problem.

  • Synaptic fully works! Can install packages via it.

  • KDE Partition Manager fully works (with my mod to add pkexec in the .desktop)!

  • Mounting an external drive (vbox VDI) in Thunar: This still doesn’t work. Click on the drive in Thunar devices list, nothing happens.

So this still isn’t a Whonix-wide fix to the current broken pkexec.

1 Like
27

Are you sure you enabled thunar-volman? It’s disabled by default.

2 Likes
28

Which change specifically by security-misc breaks pkexec? I need to find out to be able to report a bug against pkexec.

1 Like
29

I don’t think it’s because of security-misc but anon-base-files as it locks the root account.

https://github.com/Whonix/anon-base-files/blob/master/debian/anon-base-files.postinst#L122

30

Not the cause.
pkexec does not mind the root password.
proc-hidepid breaks pkexec.

31

That doesn’t make sense. pkexec is setuid-root. It runs as the root user so hidepid=2 won’t affect it.

Disabling proc-hidepid.service doesn’t fix the issue either.

1 Like
32

I don’t have an explanation but

sudo systemctl mask proc-hidepid

and reboot

fixed pkexec issues for me. Reliably. Reproduced many times on and off.

1 Like
33

Disabling proc-hidepid.service actually does work for me. It didn’t before for some reason (probably because I still had the /sys restrictions enabled).

Hardening - Debian Wiki talks about polkit dropping privileges and needing an exception although there isn’t a polkitd user.

1 Like
34

I only managed to fix pkexec by allowing the user user unrestricted access to /proc. This means polkitd drops privileges to the current running user instead of any special polkit user. We should make a bug report and try to make them bring back the polkitd user.

1 Like
35

You mean this?

1
1463×570 36.1 KB

If so, well I then installed gvfs-backends and gvfs-fuse packages, restarted, then ticked ‘Enable Volume Management’ to apparently fix that:

2
2463×544 29.4 KB

I even went into its configuration to tick to auto mount hotplugged and inserted external drives.

But…still doesn’t work. I click on my drive under Devices in Thunar, nothing happens. In my main Whonix, my own insecure hacky fix continues to work.

Hope that helps. The above newer posts sound promising.

2 Likes
36
2 Likes
37

Two options to solve this.

  • disable proc-hidepid by default
  • perhaps redirect pkexec to lxqt-sudo / sudo

The second option is currently being tested by me.

The wrapper could use some review. See:

For now only in developers repository which I don’t recommend for users/testers.

1 Like
38

Hello. I read the comment in this thread that my specific issue with Zulucrypt throwing an error are probably unrelated to the subject of this thread.

That said, I wanted to offer some anecdotal details from my experience since the last time I posted a comment on this thread.

If it would be better to open a new thread about this, I will gladly do so.

Steps in this process:

(1) Everything is working properly in my instance of Whonix.

(2) Update/upgrade Whonix to Debian 10/Buster base as instructed.

(3) After reboot, I first got the error regarding “pkexec”, and found this thread. (The only app I used that this affected was Zulucrypt.)

(4) Applied the posted/possible workaround, and was able to start Zulucrypt but not able to open an encrypted volume that had worked fine before upgrade/update to Debian 10/Buster base. That’s the error I had posted about previously that might be unrelated to the “pkexec” error.

Since then:

(5) I opened the original instance of Whonix VM’s (from which this instance was cloned back in July). I went through the exact steps of updating/upgrading as above and duplicated every one of the steps with exactly the same results.

(6) I installed “gnome-disk-utility” which has the ability to attach and open LUKS-encrypted images/volumes. It attached okay, but upon attempting to decrypt it, it throws this error upon failure:

“error unlocking /dev/loop0: The function ‘bd_crytpo_luks_open_blob’ called but not implemented1 (udisks-error-quark; 0)”

Conclusion: I will gladly post this as a new thread if advisable; it is possible that the error involving “pkexec” and this problem of decrypting a previously created LUKS volume are separate issues. The certain overlap is that both manifestations began occurring at the time of updating/upgrading the existing Whonix instance to the Debian 10/Buster base.

Thank you.
Amoretpax

2 Likes
39

Or 3:

  • Get Debian to bring back the polkitd user so we can add it to a proc group

Redirecting pkexec to lxqt-sudo seems like an incredibly hacky way to do this.

if ! mount | grep “/proc” | grep “hidepid=2”

Why grep for /proc then for hidepid=2? hidepid=2 is only a mount option for /proc. It can’t be set elsewhere so grepping for /proc is redundant.

1 Like
40

Please try if this workaround solves your issue:

If not solved: new thread

If solved: no new thread

1 Like