Are you sure you enabled thunar-volman? It’s disabled by default.
2 Likes
Which change specifically by security-misc breaks pkexec? I need to find out to be able to report a bug against pkexec.
1 Like
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
Not the cause.
pkexec does not mind the root password.
proc-hidepid breaks pkexec.
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
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
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
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
You mean this?
If so, well I then installed
gvfs-backends and gvfs-fuse packages, restarted, then ticked ‘Enable Volume Management’ to apparently fix that:
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
2 Likes
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
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
Or 3:
- Get Debian to bring back the
polkitduser so we can add it to aprocgroup
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
Please try if this workaround solves your issue:
If not solved: new thread
If solved: no new thread
1 Like
This could be done in parallel. But I don’t have much hope given the non-activity of that bug report and little polkit package version number bumps throughout Debian releases. It’s probably “patches welcome”. Also this doesn’t solve this issue in Whonix 15 since polkit changes would have to wait until Debian bullseye based Whonix for the fixed polkit version to trickle down.
Wasn’t sure about it. Just wanted to make sure non-root users cannot influence this behavior.
Agreed. So for Whonix 15 either pkexec to lxqt-sudo redirection or disabling proc-hidepid by default. Which one would you suggest?
1 Like
hidepid is a really useful feature and as Whonix is a security focused distro, I think it should stay enabled by default with the redirect at the cost of minor breakage.
1 Like
- In Whonix testers repository this is fixed:
- In Whonix 15.0.0.6.5-developers-only and above this is fixed.
(15.0.0.6.5-developers-only has some unrelated imperfections. Won’t be released. Higher Whonix release tag and testers-only release coming soon.)
The pkexec wrapper in upgraded security-misc package is functional.
Fixed meaning: I successfully used: gdebi, synaptic, gparted.
Fixed:
1 Like
Anything that remained unfixed here?
Yes. Thunar mounting (or auto mounting) of external drives (e.g. a vbox VDI). I can continue to test for you on a Developer OVA. Its current status is it still doesn’t work without giving UDisks2 an explicit policykit exception which is obviously dangerous and not ideal.