Hi,
I’ve been using VeraCrypt for a while on a Whonix app qube.
With the latest template version (Q4.2), I haven’t been able to open my encrypted drive because it asks for admin rights, which were removed. How can I make it work with the newly implemented isolation without either removing it or giving the user full sudo rights as was done before?
Permission denied:
/usr/bin/sudo
VeraCrypt::CoreService::StartElevated:435
Thank you
As I understand it, I either need to run the full program as root or enable sudo privileges for the user. Using privleap doesn’t seem doable here, unless I’m mistaken.
I will clone the template and revert to the previous sudo behavior. That seems to be the best option in my case. Thank you
VeraCrypt does not work with privleap. Many of us need VeraCrypt, thus we can not use the new isolation mode.
Why is VeraCrypt not included on the apps already installed?
Thank you Patrick.
Because there’s cryptsetup / LUKS installed by default. See also:
Also due to:
This is still not a good option for restoring the veracrypt workflow, and I haven’t been able come up with an adequate solution ever since the user-sysmaint split, aside from restoring unrestricted admin mode.
I was able to get zuluCrypt to open a volume using privleap, but you have to hardcode the name of the container into your command (which is not so bad on it’s own), yet even worse, you have to hardcode the password into the command as well, reducing any security benefits almost completely. Attempting to omit the password flag from the command returns in an error related to pkexec (or whatever Whonix uses) not allowing interactive entering of passphrases.
The volume is also mounted in /run/media/private/root by default, meaning it’s inaccessible to the user. To fix this, I tried adding the -K user flag to the command, but for some reason I would get a permission denied error. Only the -M flag works, by creating a mirror of the container in /run/media/public, but I don’t know how much that compromises security.
So, if the only way to mount and unmount encrypted volumes in the current Whonix version is to hardcode the passwords into your privleap custom actions, then having them in the first place is pretty much useless, as one could easily just read the contents of the files in /usr/bin to get the passwords. It seems like the Whonix devs don’t want people to use encrypted containers for some reason.
Full Disk Encryption (FDE) is not a magic solution, as most people use their computers for other things and if an attacker/adversary were to gain control of the host OS, they could see through Virtualbox/virt-manager configs that Whonix exists on the system. At least having the option to encrypt files inside Whonix would be a nice extra precautionary step (strategic dominance?), as they are presumably more sensitive than whatever’s on the host.
I really wanted to give user-sysmaint a chance, but it seems like it’s impossible to use it concurrently with encrypted containers.
We’re improving the security of the system. While doing so, we cannot always foresee all the diverse workflows which get broken by a particular feature.
The user-sysmaint-split feature is important. See Rationale for Protecting the Root Account.
Non-root enforcement is the industry standard for Android, iOS and any locked down Linux based operating system. At time of writing, most [0] Linux desktop distributions lag behind in security. Hence, user-sysmaint-split has been implemented in Kicksecure.
One reason why user-sysmaint-split can be securely [1] and easily [2] uninstalled is to allow user freedom, to support users with less common workloads.
One would need to develop a mechanism to prompt for the password during the user session. The privileged process spawned by privleap would need to spawn a password entry command line interface or graphical user interface, wait for the password to be entered, then continue.
I don’t know if there is much hope for VeraCrypt / ZuluCrypt. Maybe except if their respective developers are interested to work on user-sysmaint-split compatibility or a contributor doing that.
Container based encryption in user session might be simpler to implement using cryptsetup as it is a “simple command line program”, it is not intertwined with pkexec.
[0] Just to avoid saying “all”. Hard to find exceptions at this point. But wording defensively just in case.
[1] Securely here means that the feature can be disabled with the consent of the user without making it less secure for users who don’t disable the feature.
[2] As simple as a boot menu entry.
@Patrick do you see any security related issues with the below setup? This is what I do so that I don’t even need root/sudo in user mode to mount my encrypted backup disk.
Attach storage to VM on host:
virsh -c qemu:///system attach-disk \
--domain Whonix-Workstation \
--source /dev/disk/by-uuid/107e1edc-0913-4575-a2d9-1d4954e84715 \
--target vdb \
--targetbus virtio \
--driver qemu \
--subdriver raw \
--type disk \
--sourcetype block \
--persistent
Add polkit rule /etc/polkit-1/rules.d/10-udisk2.rules. This will require sudo so it must be done in the sysmaint mode.
sudo nano /etc/polkit-1/rules.d/10-udisk2.rules
polkit.addRule(function(action, subject) {
if (action.id.match("org.freedesktop.udisks2.") && subject.isInGroup("storage")) {
return polkit.Result.YES;
}
});
sudo chown polkitd:root /etc/polkit-1/rules.d/10-udisk2.rules
Add yourself to the storage and plugdev groups. This will require sudo so it must be done in the sysmaint mode.
sudo addgroup --system storage
sudo usermod -aG storage,plugdev user
Then this should work in user mode.
udiskctl unlock \
--block-device=/dev/disk/by-uuid/107e1edc-0913-4575-a2d9-1d4954e84715
Should also be able to click on the volume in Thunar or whatever. Change the uuid to whatever your device is.
I don’t have much comments.
Using a polkitd drop-in configuration snippet is clever to work around the polkit prompt. If that works, it’s great.
Minor: I don’t see why it need to be owned by polkitd.
Why required? Why both groups?
It seems if it’s not polkitd:root the rule is not read and still asked for authentication to mount.
plugdev is needed to mount the filesystem anyway so the storage group is redundant. The storage group doesn’t really add any security benefits when the user is in both groups.
Add yourself to the
plugdevgroup. This will requiresudoso it must be done in the sysmaint mode.sudo usermod -aG plugdev user
I would change instructions, but it seems I can’t edit my post.
Would you like to add documentation here?
Wow, your solution could help many Zulucrypt and VeraCrypt users! Write an instruction on the wiki and users will stop blaming Patrick for inconveniences 
And write an instruction for Kicksecure-Host please
Hi Patrick. You know Veracrypt does not use udisk, so these instructions are useless. Please reconsider allowing us again to mount Veracrypt containers on Whonix.
I don’t really understand what the issue is; the ability to mount Veracrypt containers was never removed. user-sysmaint-split was designed with full knowledge that it probably would break some workflows, and so removing user-sysmaint-split from Whonix is fully supported so that users with those workflows can still work. For convenience, there’s an option in the boot menu for doing this quickly:
Whonix without user-sysmaint-split is (or at least is designed to be) exactly identical to how Whonix used to operate before user-sysmaint-split. If you want to be allowed to mount Veracrypt containers on Whonix, just select that boot option, follow the on-screen instructions, and you’re good to go.
At the moment there isn’t sufficient development resources to allocate to the job of making user-sysmaint-split and Veracrypt compatible. Depending on how Veracrypt works, privleap might need a much richer set of authentication and IPC features to be able to work with it properly, and it would require close scrutiny of how Veracrypt works in order to avoid issues similar to the zuluCrypt root escalation vuln that was found a few months ago (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1108288). It’s because of vulns like this that we made user-sysmaint-split in the first place, and it’s why we pre-install it.
