New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
macOS: Volumes mounted by VeraCrypt are visible and accessible (read + write) to other users #1296
Comments
Devices seem to be always mounted with To demonstrate this is not a VeraCrypt specific issue we can remove it from the equation:
Here we created an empty file and attached it as a raw block device. In Disk Utility you can format the newly attached virtual device. Next in Finder you right click the mounted device and go "Get Info", make sure "Ignore owner permissions" is unchecked and make sure your account only has read write, everyone has no access and staff has no access. If you log into another profile now, all access to the folder where the filesystem is mounted at is blocked, but anyone can launch Disk Utility and clone your block device and access your data. If you're just trying to block non-tech savvy people from snooping at your files, blocking the access to the mountpoint might suffice, but it is in no way a real protection measure. I am not very familiar with macOS and don't claim to be an expert, but I don't know if there is a way to restrict access to the underlying block device, not just the mount point. The permission troubles seem to have some discussion, but with no great results, see this. EDIT 4/2/2024: Fixed command |
@Jertzukka Well, I can't contribute much to your analysis, as stated I'm not an expert in these matters. If the conclusion is that it's not possible to protect VeraCrypt volumes against other users in the system, then I don't have much choice but to (grudgingly) accept that. After playing around with The
It's not specified in the man page what happens when you omit the Using
|
Yes, it was supposed to be |
On macOS, when I mount a VeraCrypt volume from a file container while logged in as user A, I can then switch to another user B and view the mounted volume's content (e.g. in the Finder, or in a Terminal.app session). Users A and B both are non-admin users.
I don't know enough about the underlying issues to lay the blame on any one in particular (macOS, VeraCrypt, FUSE?), but what I definitely can say is that I cannot trust my Mac to be left alone while a VeraCrypt volume is still mounted.
Expected behavior
A VeraCrypt volume should remain private to the user who mounted it. Other users should neither see the volume, nor be able to read the volume content, nor be able to write the volume content. The restrictions should be in place both in the graphical UI and in a Terminal.app session.
Observed behavior
Once a VeraCrypt volume is mounted by a user, all other users on the system can see it, and they can read and write the volume content. Restrictions are missing both in the graphical UI and in a Terminal.app session.
Steps to reproduce
Steps 6-9 are equally possible in a Terminal.app session with command line tools such as
ls
andvi
.Terminal.app output
Here is the output of an
ls
command executed as useruserA
who mounted the VeraCrypt volume. As you can see, the VeraCrypt volumeNO NAME
is mounted with permissions that make it wide open for any user to snoop around inside. What I would like to see here is that theNO NAME
volume has the same set of permissions as thedaten-1
volume (which is a Samba network share mounted by macOS on behalf ofuserA
).Here is the output of an
ls
command executed as another useruserB
who did not mount the VeraCrypt volume. Interesting is that the owner of theNO NAME
volume is now shown asuserB
, even though it wasuserA
who mounted the volume - I don't know enough about the underlying macOS mechanics to explain what's going on here. Also interesting to see is that the Samba volumedaten-1
belonging touserA
is not visible, although a "permission denied" error is printed.For comparison, here is the output of the
ls
command executed as an administrator useradmin
, first without and then withsudo
.Note: The "@" character in the "drwxrwxrwx@" permission list for the
NO NAME
volume indicates that the folder has an extended attribute in the file system (extended attributes are a Mac specific mechanism to attach metadata to a file). Here is the metadata in hex form (indicating the MSDOS volume ID):Your Environment
VeraCrypt version: 1.26.7
macFUSE version: 4.5.0
Operating system and version: macOS Ventura 13.5.2 (Intel)
Historical Note
This is not a new issue. It already existed in TrueCrypt, and has been "inherited" by VeraCrypt. I submitted a problem report on the original TrueCrypt website in September 2009 without getting any response. I also submitted this issue in 2014 on the CipherShed project, where some discussion took place but to my understanding no conclusion was reached except that eventually it was labeled as a bug. After I was recently annoyed again by this issue I decided to renew my attempt to get it analyzed and possibly fixed - hence this submission.
The text was updated successfully, but these errors were encountered: