Volumes mounted by TrueCrypt are visible/accessible to other users

[herzbube]

On Mac OS X, when I mount a TrueCrypt 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). I believe this is a bug, as the content of the TrueCrypt volume should remain private to the user who mounted it. I don't know enough about the underlying issues to lay the blame on any one in particular (Mac OS X, TrueCrypt, FUSE?), but what I definitely can say is that I cannot trust my Mac to be left alone while a TrueCrypt volume is still mounted.

This is how my mounted volumes' mount points look like inside a Terminal.app session. As you can see, the TrueCrypt volume PRIVATE is mounted with permissions that make it wide open for any user to snoop around inside.

caradhras:~ --> ls -l /Volumes/
total 72
lrwxr-xr-x   1 root   admin      1 27 Jul 17:52 Macintosh HD -> /
drwxrwxrwx@  1 admin  staff  16384 31 Dez  1979 PRIVATE
drwx------   1 admin  staff  16384  9 Jun 17:06 data

What I would like to see here is that the PRIVATE volume has the same set of permissions as the data volume (which is a Samba network share mounted by Mac OS X). Ideally, the Finder should not display the PRIVATE volume at all, but if it does, the user should not be able to access the volume's content.

I am using TrueCrypt 7.1a on Mac OS X 10.9.4. The issue is not new, though, it already existed in previous versions of TrueCrypt; I don't recall the specific version I used then, but I submitted a problem report on the original TrueCrypt website in September 2009 - without getting any response.

I am aware that CipherShed has not made its initial rebranding release yet, so please forgive me for reporting this already. However, because CipherShed is based on the TrueCrypt 7.1a code base, I am quite confident that the issue will be present in your initial release as well.

[GigabyteProductions]

Did TrueCrypt make the folder it's mounting your volume on?

[rockihack]

/Volumes/ is the default mount point on mac os x.
(TrueCrypt created the symbolic link /Volumes/PRIVATE with drwxrwxrwx)

[GigabyteProductions]

Ah, well I'm not sure about Mac (since I use Linux), but symbolic links are always like that on Linux, the permissions will always me limited to what it links to. For example, a folder with drwx------ can exist on /media/mountpoint, and i can do "ln -s /media/mountpoint /media/linktomountpoint" which will result in a link called /media/linktomountpoint with the permissions of lrwxrwxrwx, but if I access that from the user nobody (or just any user that doesn't own the original folder), it will give me permission denied as if I accessed the original folder.

[herzbube]

@GigabyteProductions The /Volumes/PRIVATE folder does not exist prior to mounting the file container.

@rockihack As far as I can tell, /Volumes/PRIVATE is not a symbolic link. Here is a bit of additional information from the df command (in case you should notice: yes, this time I am logged in with a different user than when I wrote the original issue description):

caradhras:~ --> df
Filesystem                 Size   Used  Avail Capacity  iused      ifree %iused  Mounted on
/dev/disk0s2              465Gi  214Gi  251Gi    47% 56135465   65792764   46%   /
devfs                     205Ki  205Ki    0Bi   100%      711          0  100%   /dev
map -hosts                  0Bi    0Bi    0Bi   100%        0          0  100%   /net
map auto_home               0Bi    0Bi    0Bi   100%        0          0  100%   /home
//patrick@pelargir/data   92Gi   13Gi   78Gi    15%        0 18446744073709551615    0%   /Volumes/data
TrueCrypt@osxfuse0          0Bi    0Bi    0Bi   100%        0          0  100%   /private/var/folders/v9/d_6pbwxd72b1mbq_9vhfcy6w0000gp/T/.truecrypt_aux_mnt1
/dev/disk2                9.7Mi  177Ki  9.5Mi     2%      512          0  100%   /Volumes/PRIVATE

For what it's worth, the "@" character in the "drwxrwxrwx@" permission list 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:

caradhras:~ --> xattr -lx /Volumes/PRIVATE
com.apple.filesystems.msdosfs.volume_id:
00000000  5F B6 DA FB                                      |_...|
00000004

I don't know why the volume has this ID, but it's correct that the volume has an MSDOS filesystem.

[rockihack]

Can you test to mount the volume with hdiutil?
hdiutil attach /dev/disk2 -plist -noautofsck -imagekey diskimage-class=CRawDiskImage -nomount

Please report if a mount point is created and what are the permissions?

CipherShed/src/Core/Unix/MacOSX/CoreMacOSX.cpp

Line 109 in e8529e9

void CoreMacOSX::MountAuxVolumeImage (const DirectoryPath &auxMountPoint, const MountOptions &options) const

[herzbube]

Hm, I don't think that the command you want me to test will ever create a mount point - after all the command line includes the argument -nomount. That being said, I still tried the following things:

1. If the volume is currently not mounted in TrueCrypt, hdiutil fails with the following error message:

caradhras:~ --> hdiutil attach /dev/disk2 -plist -noautofsck -imagekey diskimage-class=CRawDiskImage -nomount
hdiutil: attach failed - Es existiert keine Datei und kein Ordner dieser Art

(the German sub-message probably translates to "No such file or directory" or something similar)

2. If the volume is already mounted in TrueCrypt, hdiutil prints the following plist, but does not create a new mount point:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>system-entities</key>
    <array>
        <dict>
            <key>dev-entry</key>
            <string>/dev/disk2</string>
            <key>mount-point</key>
            <string>/Volumes/PRIVATE</string>
            <key>potentially-mountable</key>
            <true/>
            <key>volume-kind</key>
            <string>msdos</string>
        </dict>
    </array>
</dict>
</plist>

3. If I manually unmount /dev/disk2 and then run the command, hdiutil prints a slightly different plist, but still does not create a new mount point:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>system-entities</key>
    <array>
        <dict>
            <key>dev-entry</key>
            <string>/dev/disk2</string>
            <key>potentially-mountable</key>
            <true/>
            <key>volume-kind</key>
            <string>msdos</string>
        </dict>
    </array>
</dict>
</plist>

I am not sure what the CoreMacOSX::MountAuxVolumeImage() function that you reference tries to achieve:

• It evidently does not want hdiutil to perform the mount (hence the -nomount option)
• Instead, it wants hdiutil to produce a plist that can be parsed (hence the -plist option)
• After parsing the plist, the function then seems to instruct FUSE to perform the mount

With the current data from my test, though, the function passes /dev/disk2 to hdiutil and then gets back the same device in the plist. The question is: Are there cases where hdiutil prints a different device than it receives? I can only speculate, but my guess is that 1) no, the device will always be the same, but 2) the actual purpose of executing hdiutil is to perform some kind of "probing", delegating to the system the checks whether the device exists, whether the volume type is correct, etc.

[rockihack]

Yes, I wasn't completely sure about the mount-point creation.
It will create one if the filesystem on the drive is mounted
but not when a raw drive is attached.

The problem without decryption is that the volume container looks random to the os.
TrueCrypt uses "-mount required" to mount the filesystem, but also handles the decryption.

Can you mount any other volume with hdiutil and compare the mount point permissions?

[herzbube]

1. Mount the volume in a .dmg file container

caradhras:~ --> hdiutil attach ~/Downloads/ApacheDirectoryStudio-macosx-x86_64-2.0.0.v20130628.dmg 
Die erwartete CRC32-Prüfsumme ist $1D94869F
/dev/disk2              Apple_partition_scheme          
/dev/disk2s1            Apple_partition_map             
/dev/disk2s2            Apple_HFS                       /Volumes/Apache Directory Studio

caradhras:~ --> ls -ld /Volumes/Apache\ Directory\ Studio
drwxr-xr-x@ 9 patrick  staff  306 Jun 28  2013 /Volumes/Apache Directory Studio

2. Mount a volume from an external USB hard disk

caradhras:~ --> hdiutil attach /dev/disk1s2
<system pops up a dialog and asks me for admin password>

caradhras:~ --> ls -ld /Volumes/HFSX
drwxr-xr-x  38 patrick  staff  1360 Jul 30 15:01 /Volumes/HFSX

I noticed that when I switch to a different user, the mount point permissions "magically" change to match the new user.

caradhras:~ --> ls -ld /Volumes/HFSX
drwxr-xr-x  38 admin  staff  1360 30 Jul 15:01 /Volumes/HFSX
               ^^^^^

I do not know what sorcery this is. The result is the same if I use the GUI for the user switch, or if I do it on the command line via su admin. Interestingly, the permissions do not change for the .dmg file mount point.

[rockihack]

By default, unknown HFS filesystems on "external" devices (including disk images) mount with their owners ignored (mount -o noowners). When owners are ignored, the system dynamically substitutes the current rent user's identify for any owners recorded in the filesystem. When creating new files, a special UID and GID of _unknown are recorded on the disk. Even if a filesystem is later mounted with on-disk owners honored, files with stored UID or GID of _unknown will continue to substitute the current user's credentials any time the given file is accessed. The net result is that shared volumes behave as expected even when connected to systems where their on-disk owners are honored.

On modern OS X systems, root (UID 0) can "see through" the _unknown user mappings. Thus
sudo ls -l /Volumes/imageVol
will show whatever is really stored in the filesystem (possibly _unknown) regardless of whether owners
are currently being respected on that volume. In contrast, non-root users will see themselves any time
owners are ignored (either via mount -o noowners or stored _unknown): mary running ls -l will see that
mary owns any owners-ignored filesystems objects while joe running ls -l on the same objects will see
that joe owns them.

see: PERMISSIONS VS. OWNERS
https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/hdiutil.1.html

[herzbube]

So no sorcery then :-) thanks for the pointer.

[Deleetdk]

This is also a problem on Windows 8.1, using the last safe version of TrueCrypt. Devices mounted on user A are available to all other users.

[GigabyteProductions]

I think that's a Windows issue, though. I don't think Windows has a permissions system for drives themselves. You'd have to use a file system with a permission system, such as NTFS, and basically implement a whitelist with the ACL options.

[Deleetdk]

I am using NTFS formatted drives.

[GigabyteProductions]

Can other users access the volume when you have the permissions setup to only let you see?

[rockihack]

Devices mounted on user A are available to all other users.

As far as I know all admins can access all mounted drives.
Did you try with restricted users?

[Deleetdk]

Did you try with restricted users?

Good idea. I made a new user without administrator rights but it can still see the mounted drives.

[chromeronin]

Still an issue with MacOS 10.15.5 Catalina and VeraCrypt 1.24-Update4.
When I mount a volume as one user, another logged on user on the Mac can also see the contents of the mounted veracrypt volume. The other user is NOT an administrator user.