0

Question

Does a link, symlink, or macOS finder aliases to a file/directory located on a version 1 FileVault partition/container/volume to a partition not under the FileVault coverage allow unencrypted access?

 # Example
/Volumes/UnEncryptedVolume/Reference-To-Unlocked-FileVault-File     ->   ~/THE_FILEVAULT_FILE

Constraints

  • APFS formatted SSD
  • Permissions are not restrictive permissions on Database volume. All Users & Staff grouped Users can access it.
  • User is logged in, unlocking the FileVault volume
  • Link is either soft or hard, has standard permissions
  • Finder created alias has default permissions
  • Original file is again, standard permissions even if under $HOME (Change those UMASKS newcomers! :))
  • Original file is on the FileVault container
  • Database is on the same Disk, but a different container.
  • Disk is APFS formatted (composed of containers, not volumes or partitions, apfs is friggin' confusing IMO)

File System Structure

My Internal SSD partition structure (not a OEM SSD for those curious)

+-- Container disk1 
|   ====================================================
|   APFS Container Reference:     disk1
|   Size (Capacity Ceiling):      999995129856 B (1000.0 GB)
|   Capacity In Use By Volumes:   314911416320 B (314.9 GB) (31.5% used)
|   Capacity Not Allocated:       685083713536 B (685.1 GB) (68.5% free)
|   |
|   +-< Physical Store disk0s2 
|   |   -----------------------------------------------------------
|   |   APFS Physical Store Disk:   disk0s2
|   |   Size:                       999995129856 B (1000.0 GB)
|   |
|   +-> Volume disk1s1 
|   |   ---------------------------------------------------
|   |   APFS Volume Disk (Role):   disk1s1 (Data)
|   |   Name:                      MacOS - Data (Case-insensitive)
|   |   Mount Point:               /System/Volumes/Data
|   |   Capacity Consumed:         138089828352 B (138.1 GB)
|   |   FileVault:                 Yes (Unlocked)
|   |
|   +-> Volume disk1s2 
|   |   ---------------------------------------------------
|   |   APFS Volume Disk (Role):   disk1s2 (Preboot)
|   |   Name:                      Preboot (Case-insensitive)
|   |   Mount Point:               Not Mounted
|   |   Capacity Consumed:         80568320 B (80.6 MB)
|   |   FileVault:                 No
|   |
|   +-> Volume disk1s3 
|   |   ---------------------------------------------------
|   |   APFS Volume Disk (Role):   disk1s3 (Recovery)
|   |   Name:                      Recovery (Case-insensitive)
|   |   Mount Point:               /Volumes/Recovery
|   |   Capacity Consumed:         525770752 B (525.8 MB)
|   |   FileVault:                 No
|   |
|   +-> Volume disk1s4 
|   |   ---------------------------------------------------
|   |   APFS Volume Disk (Role):   disk1s4 (VM)
|   |   Name:                      VM (Case-insensitive)
|   |   Mount Point:               /private/var/vm
|   |   Capacity Consumed:         3222294528 B (3.2 GB)
|   |   FileVault:                 No
|   |
|   +-> Volume disk1s5 
|   |   ---------------------------------------------------
|   |   APFS Volume Disk (Role):   disk1s5 (System)
|   |   Name:                      MacOS (Case-insensitive)
|   |   Mount Point:               /
|   |   Capacity Consumed:         11236782080 B (11.2 GB)
|   |   FileVault:                 Yes (Unlocked)
|   |
|   +-> Volume disk1s6 
|       ---------------------------------------------------
|       APFS Volume Disk (Role):   disk1s6 (No specific role)
|       Name:                      Database (Case-insensitive)
|       Mount Point:               /Volumes/Database
|       Capacity Consumed:         161548357632 B (161.5 GB)
|       FileVault:                 No
|

3
  • 1
    Each of the three mechanisms you reference are fundamentally different. Hard or symbolic links behave differently than aliases and with APFS, copy on write and snapshots all are entwined. None of them change the content on the disk, however - they all are metadata, not data. I’m not sure I can follow enough what your problem to solve is to answer this, though. – bmike Feb 13 at 21:55
  • 1
    Symlinks are just notes for the OS about where the actual target file can be found. If you can read the target you can also read it via the symlink. If you can‘t read the target you can‘t read it via the symlink either. The things you list under Constraints and File System Structure are totally irrelevant for the question here. – nohillside Feb 13 at 21:58
  • And you can‘t have hardlinks across volumes, actually – nohillside Feb 13 at 21:59
2

The answer is no. Symlinks do not somehow "circumvent" FileVault encryption.

Symlinks are always "soft" by the way.

4
  • Perhaps I should elaborate on how macOS also has a OS based security regulation for file access that isn't clear on how it relates to actual file permissions. Full Disk access only covers your booted disk, not other volumes/partitions/containers... which I thought would be understood as this is about macs. I'll change my terms for links vs symlinking. – Jahhein Feb 13 at 21:01
  • I however don't see this as correct. There is no actual reasoning or much of anything that answers why. – Jahhein Feb 13 at 21:03
  • 1
    I know about "Full Disk Access" and the like - it is part of a security model not unlike what is found on other operating systems. It doesn't come into play at all for this question, which concerns whether or not symbolic links somehow would allow one to bypass FileVault encryption. – jksoegaard Feb 13 at 21:36
  • Can you explain why you do not think my answer is correct? (it is correct, but I just wanted to hear your explanation, as that would allow me to more precisely tell you why it is not so... the main question here is really unclear as to why one would think that symbolic links somehow would 'undo' encryption, if I knew why or where that suspicion comes from, it would be a lot easier to give a better answer) – jksoegaard Feb 13 at 21:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .