macOS: Volumes mounted by VeraCrypt are visible and accessible (read + write) to other users

[herzbube]

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

1. Log into macOS as non-admin user A.
2. Use VeraCrypt to create a new file container with filesystem FAT16.
3. Mount the file container with VeraCrypt.
4. Create a text file with a couple of words in the mounted volume.
5. Switch to a different non-admin user B. (user A remains logged in and still has the VeraCrypt volume mounted)
6. As user B, open a Finder window => The volume is visible in the Finder window's sidebar.
7. Select the volume in the Finder window => The text file is visible in the Finder window.
8. Open the text file in a text editor => The text file is readable.
9. Change the content and save the text file => The text file is writeable.

Steps 6-9 are equally possible in a Terminal.app session with command line tools such as ls and vi.

Terminal.app output

Here is the output of an ls command executed as user userA who mounted the VeraCrypt volume. As you can see, the VeraCrypt volume NO 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 the NO NAME volume has the same set of permissions as the daten-1 volume (which is a Samba network share mounted by macOS on behalf of userA).

$ ls -l /Volumes
total 64
lrwxr-xr-x   1 root     wheel      1  9 Dez 18:23 Macintosh HD -> /
drwxrwxrwx@  1 userA  staff  16384  1 Jan  1980 NO NAME
drwx------   1 userA  staff  16384 26 Sep  2021 daten-1

Here is the output of an ls command executed as another user userB who did not mount the VeraCrypt volume. Interesting is that the owner of the NO NAME volume is now shown as userB, even though it was userA 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 volume daten-1 belonging to userA is not visible, although a "permission denied" error is printed.

$ ls -l /Volumes
ls: daten-1: Permission denied
total 32
lrwxr-xr-x   1 root       wheel      1  9 Dez 18:23 Macintosh HD -> /
drwxrwxrwx@  1 userB  staff  16384  1 Jan  1980 NO NAME

For comparison, here is the output of the ls command executed as an administrator user admin, first without and then with sudo.

$ ls -l /Volumes
ls: daten-1: Permission denied
total 32
lrwxr-xr-x   1 root   wheel      1  9 Dez 18:23 Macintosh HD -> /
drwxrwxrwx@  1 admin  staff  16384  1 Jan  1980 NO NAME

$ sudo ls -l /Volumes
Password:
total 64
lrwxr-xr-x   1 root      wheel         1  9 Dez 18:23 Macintosh HD -> /
drwxrwxrwx@  1 _unknown  _unknown  16384  1 Jan  1980 NO NAME
drwx------   1 userA   staff     16384 26 Sep  2021 daten-1

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):

$ xattr -lx /Volumes/NO\ NAME
com.apple.filesystems.msdosfs.volume_id:
00000000  7B 9A 4D 67                                      |{.Mg|
00000004

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.

[Jertzukka]

Devices seem to be always mounted with noowners mount option that makes setting any permissions impossible on the mountpoint. But these mount options are not set by VeraCrypt, they seem to be defaults OS wide. But the issue with mounted devices being accessible by other users doesn't seem to be a VeraCrypt specific issue generally. We can even show that even without noowners the permissions are still not enough to prevent unauthorized access.

To demonstrate this is not a VeraCrypt specific issue we can remove it from the equation:

dd if=/dev/zero of=./blockfile bs=1M count=50
hdiutil attach -imagekey diskimage-class=CRawDiskImage -nomount -owners on blockfile

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

[herzbube]

@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 hdiutil and Disk Utility, I just have a few comments/observations which may or may not be helpful...

The hdiutil command in your comment did not work on my macOS (13) because the -owners argument requires a parameter, either on or off. So a working command would read, for instance:

hdiutil attach -imagekey diskimage-class=CRawDiskImage -nomount -owners on blockfile

It's not specified in the man page what happens when you omit the -owner argument, but in an experiment it seemed to behave like -owners off.

Using on and off values did not have any effect on visibility of the mounted volume to other users, i.e. other users would always see the mounted volume. But the choice of filesystem on the volume has an effect on the permissions used on the mount point.

# FAT and ExFat don't care about -owners, they always mount with permissions 777
drwxrwxrwx  1 userA  staff  4096  1 Jan  1980 /Volumes/FAT/
drwxrwxrwx  1 userA  staff  4096  1 Jan  1980 /Volumes/ExFat/

# HFS+ with -owners on
drwxrwxr-x   5 root     wheel    238  4 Feb 13:03 hfsplus
# HFS+ with -owners off
drwxrwxr-x   5 userA  staff    238  4 Feb 13:03 hfsplus

# APFS with -owners on
drwxrwxr-x@  3 root     wheel     96  4 Feb 13:07 apfs
# APFS with -owners off
drwxrwxr-x@  3 userA  staff     96  4 Feb 13:07 apfs

[Jertzukka]

Yes, it was supposed to be -owners on, just a mistake when retyping it here as I didn't have shared clipboard setup for my VM. I believe owners doesn't have impact on the underlying device being visible to other users, rather it just lets the person mounting it to set permissions on the mountpoint.