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.

19
  • 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
  • The end result of this question is if you just hooked up the drive to another computer if that symlink would expose the data. (I took a mac's filevault disk and read it from a linux machine). You basically keep saying I'm an idiot for asking this question and I should just delete it however zero knowledge of how a macOS system gives that disk special treatment or the OS sets limitations rather than the files sytem (I.E. Full disk access is an OS feature and completely moot if a linux system read it)
    – Jahhein
    May 12 at 20:28

You must log in to answer this question.

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