veracrypt
Mounting volume requires root privileges
After decrypting the volume VeraCrypt asks for the root password for mounting it. This can't be true. I do administer a system with aprox. 800 users. And you want me to grant root access to all of them? No way. I'm not even comfortable putting veracrypt in sudoers – this just feels like the wrong way of doing it. Why does the user require root privileges for mounting her volume? Users don't need root privileges for mounting their USB thumb drives. I cannot see why mounting a VeryCrypt volume should be different? I guess that udev rules are the answer to this. Is VeraCrypt missing appropriate rules? How is it done for USB-drives? How does Windows do it?
Honestly, there must be a better solution than asking for the root password.
VeraCrypt makes use of the kernel device mapper, which requires root privilege in order to operate. This is VERY different from just mounting a USB stick. Btw, this is how it is done even when using LUKS.
The root privilege is a basic requirement for mounting or accessing raw disk data. If you could do those without root priveleges, you could read files you have no permission to read (by reading and searching the raw data), and if you could mount you could mess up the VFS filesystem tree.
Cheers.
So what is the recommended scenario for deploying veracrypt in a multi-user system? It certainly can't mean granting root privileges to all our 800 users?
I second this.
Some well known alternatives like CryFS or gocryptfs manage to mount a virtual file system container with user privileges inside /home directory, no root required. Another example is Cryptomator, which can be even used as portable AppImage (no install) and decrypt a container file as user.
I would love to keep using VeraCrypt for local filesystem purposes, where files don't need to be splitted for cloud usage. But my requirement is to not require any special permissions.
@ElMostafaIdrassi Maybe some knowledge can be carried over from these alternatives to leverage non-root access? Though I am not sure about their technical implementation.
@ElMostafaIdrassi a more targeted question: would FUSE be an option for VeraCrypt in combination with file containers (not for system partition or Co.)? It effectively is used by above mentioned tools.
@ElMostafaIdrassi I see that using the kernel device mapper for raw disk access requires root privileges. But can you explain why raw disk access is needed in case of a file container? Isn't that a regular file inside the user's home directory (or on a USB drive)? Veracrypt should be able to read and write raw data of this file as the user?
@bela53 @ruedigerkupper Thank you both for raising this again. I might have omitted some details about how VC does things in my previous answer.
First, let me explain a key difference between how VC does the job of encrypting your data vs how other solutions (like CryFS...) do.
Using VeraCrypt, when you mount an encrypted file container, one of the first steps VC goes through is to create a device then mount the file container onto it. The file container may look like a simple regular file to the user but it is in fact a "virtual disk" which needs to be mounted on a block device for it to be usable by VC. Therefore, even for file containers, VC needs low-level access to the block device onto which the file container was mounted. And to mount the device in the first place, VC needs root privileges to access the kernel device mapper. For VeraCrypt, everything is a device, whether be it a file container or a system partition. VC's encryption is called block-level encryption, that is, it is done sector by sector, on the whole file system of the corresponding device.
Now, concerning the other solutions you have mentionned, they all do what is called file-level encryption, that is they encrypt files as they exist in the current filesystem. They do not require any low-level access.
On OSX, as you may or may not have noticed, there is no need for root to mount file containers. This is due to the fact that VC makes use of osxFUSE under OSX, and osxFUSE comes with its own KEXT (Kernel Extension) which runs in kernel space and pre-creates a list of devices. Therefore, VC just makes use of this list of devices and does not have to go through the hurdle of creating them itself.
However, on Linux, VC needs to manually create the devices via the kernel device mapper, and thus the need for root privileges. You have mentionned FUSE on Linux. From what I know, FUSE has an option to mount a filesystem backed by a block device which is blkdev. However, this is a privileged option, that is it requires root privileges.
So, a solution would be to have a compagnion app for VC under Linux which will NEED TO run under root privileges and which will do a similar job to what osxFUSE does, that is it will pre-create a list of devices for the VC app to use directly. This way, VC won't need any special privileges to run, only the compagnion app would.
Cheers,
@ElMostafaIdrassi very thorough answer, thanks for all the details!
I now can see, there is a fundamental difference between file-level and block-level encryption and that block-level encryption is somehow hard wired into VeraCrypt. So if I understand you correctly, VC always will have to do at least one of the following with root privilege:
- install a companion app equipped with higher permissions, so the "normal" VC app can mount as user similar to osxFUSE
- mount the file container as today
The first option at least makes VeraCrypt a bit more flexible compared to other solutions, so that normal users can mount their file container - considered the companion app has previously been installed by an administrator.
How much work would that be to split the app up like this for Linux?
@ElMostafaIdrassi, @bela53 I was just about to write the same ;-). Thanks for the explanation, I see that block-level encryption is a design principle of VC. I am sure there are good reasons for choosing it over file-level encryption.
Adding to bela53's question: Given that this "privileged companion" (system service?) is not yet available, from a pragmatic point of view:How would I deploy VC to my users? Is sudoers any option? Background: This is a German school, law requires teachers to encrypt any personal data about pupils when they store it on removable media. I.e., we are talking about USB drives. The official recommendation is Veracrypt. Meaning: if you use something else and anything goes wrong, you have a problem. As the admin this means, I must provide my users a way to access the veracrypt containera they bring on their USB drives. What is the recommended way of doing this, at this time?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}
Is there any progress regarding the aforesaid "privileged companion"? It seemed like the best idea.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
This issue has been automatically closed because it has not had recent activity. This probably means that it is not reproducible or it has been fixed in a newer version. If it’s an enhancement and hasn’t been taken on for so long, then it seems no one has the time to implement this. Please reopen if you still encounter this issue with the latest stable version. You can also contribute directly by providing a pull request. Thank you!
This issue is as valid and as urgent as it was. @ElMostafaIdrassi has suggested a fix in https://github.com/veracrypt/VeraCrypt/issues/496#issuecomment-672331738, which has simply not been implemented yet. I am sorry I am lacking the ability to do so, but I will support in testing right away. No reason closing this bug.
VeraCrypt makes use of the kernel device mapper, which requires root privilege in order to operate. This is VERY different from just mounting a USB stick. Btw, this is how it is done even when using LUKS.
But, for example, ZuluCrypt (which is the GUI for LUKS) doesn't require root privileges and works fine without it.
Also, please reopen this thread...
maybe this issue can help you : https://github.com/storaged-project/udisks/issues/894
I don't intend to continue using it until this issue is resolved, I don't want to introduce an unnecessary vulnerability on my system.
