FileVault just for /Users/[user] folders, ala Snow Leopard

Question

I know there are many questions like this on AskDifferent, but I've found none that specifically address the fairly glaring omission in more modern Mac OS builds of per-user home folder encryption via FileFault.

I don't know when Apple changed it, but older versions of OS X FileVault let you encrypt individual user's entire /Users/[user] folders. Not only was it "possible", it had a super-easy interface that seemed to encourage users to discover the functionality, and do it.

For example, I have a 2010 Macbook Pro 6,2 running Snow Leopard, with individually encrypted /Users/[user] folders. It's a great and very necessary feature for many use cases. (E.g. most scenarios where multiple users use the same macbook, either at home or work.) I will never upgrade the OS, so that I won't lose that functionality!

I'm also using a 2014 Macbook Pro 11,3 running El Capitan. FileVault has no such option to encrypt /Users/[user]. This seems like a huge step backward. Encrypting the whole drive - while great if you just happen to lose the laptop while completely powered off - will do nothing to address the common use case mentioned above. (Besides, some experts consider having encrypted home folders - plus a "guest" account with no password [plus some recovery service running] - a good way at improving your odds of recovering the machine. Not perfect and no match for professional thieves who just wipe it anyway, but better than nothing.)

So this question is really in two parts: 1) Is there a solution, ideally native, for per-user /Users/[user] encryption; and 2) Why did Apple remove such an essential feature from FileVault? Maybe only Apple knows. But often times the "why" behind controversial decisions are publicly well-known or at least known. E.g. explained in developer blogs, release notes, videos from public user/developer conferences, convention speeches, dev interviews by tech blogs, etc.

I am fully aware that it is trivially easy to create an encrypted loopback file that I can mount after login and even automate the mounting of, to store sensitive documents in. But as we know, there is quite a bit of potentially sensitive information that gets stored automagically in /User/[home], by design and as intended by Apple, including settings we may not even be aware of, that makes per-user encryption of the whole /Users/[user] folder imperative. (And besides, rather than using an encrypted loopback file, I'll just use an eCryptFS folder shared via SMB to a VM running Linux, which is my standard solution on Windows and Mac when not running Linux natively.)

BTW - I don't use TimeMachine.

Update: The fundamental reason for per-user encryption of their /User/[user] folder, with unique encryption keys, is to keep user data secure from other users of the same system. While one may disagree with giving multiple users of the same system sudo rights, there are plenty of legitimate use cases for doing so. FileVault2 only "secures" users from each other, via unix file permissions. But access to others' data is only a 'sudo chmod -R' away. That is not a real solution, to the requirement of securing users' data from each other. A real solution involves unique encryption keys of users' entire home folders (/home/[user] or /Users/[user]). Many Linux distributions make this trivially easy, as did older versions of Mac OS X / FileVault.

Update 2: System folders like Library and var "might" contain sensitive user data - either stored on purpose by negligently designed apps or leaked accidentally - but 1) almost never do in the real world of unix and unix-like systems, 2) by convention for well-behaved apps are not supposed to, and 3) most importantly - are not even physically able to in an age of increasing sandbox-iness - e.g. mac OS not allowing apps running in user mode to write to sensitive locations like that. Furthermore, just because misbehaved and/or malicious apps might leak sensitive user data to a system folder, is not a rational argument against a user or organizational requirement to secure sudo users against each other on the same system. But rather than add unnecessary debate to this question, let's just update the requirement to be:

"Secure users' data against each other with their own unique encryption keys applied to each users' entire /User/[user] folder, regardless of whether or not any/all users have sudo rights, in order to secure all of their regular user-mode data, except for the intrinsically hard-to-cover edge case of sensitive user data leaked to global system folders which of course is supposed to be impossible at the OS level when sandboxed apps are run in regular user mode."

Answer 1

I strongly advise to use full FileVault 2 encryption instead of using the FileVault 1 wannabe below!

You can mimic the FileVault 1 behavior either with an encrypted sparse bundle image or a second volume encrypted with FileVault 2. Two users are needed though and it's no elegant solution.

A proper backup of your OS X system volume before conducting one of the two how-tos below is strongly advised!

Example how-to with a sparse bundle image:

usera: admin user - usere: user with user folder which should be encrypted

• as usere create an encrypted sparse bundle image - large enough to hold all current and future usere content

• mount the image and create a folder with the name usere and modify it with chmod 744 ...

• log out as usere and log in as usera
• disable "Ignore Ownership on this volume" of the mounted sparse bundle image

• Open Terminal and enter

  su usere
  

• Now - as user usere - copy the content of the home folder of usere to /Volumes/name_of_sparsebundle_volume/usere:

  rsync -aAvX /Users/usere/ /Volumes/name_of_sparsebundle_volume/usere
  

• rename the old home folder of usere:

  mv /Users/usere /Users/userebackup
  

• exit usere - now you are usera again

• link /Volumes/name_of_sparsebundle_volume/usere to /Users:

  sudo ln -s /Volumes/name_of_sparsebundle_volume/usere /Users/usere
  

  You may have to modify the permissions of the soft link with sudo chown usere:staff /Users/usere and sudo chmod 744 /Users/usere.

• Now log out as usera and log in as usere
• Check if everything works

• If everything is fine, remove the folder /Users/userebackup:

  rm -Rd /Users/userebackup
  

Example how-to with FileVault 2:

The method is the same except that you have to encrypt an empty volume (right-click volume -> encrypt volume) instead of creating a sparse bundle image.

---

You can't log-in to usere directly because neither the encrypted sparse bundle image nor the FileVault 2 volume are mounted while the system boots. You either have to log-in as usera, mount the image/volume, log-out as usera & log-in as usere or you may log-in in console mode, mount and unlock the image/volume and log-in as usere. The latter is untested because I didn't get it to work in my VM.

---

According to Internet sources encrypted sparse bundle images are prone to (encryption) header corruption. Such a header corruption may render the image un-unlockable!

Answer 2

You can use FileVault 1 legacy home folder encryption alongside FileVault 2 full disk encryption if you are running macOS Sierra 10.12 or earlier.

High Sierra drops support for legacy FileVault though and will not install until you disable home folder encryption, so be warned.

That said, there are instructions for setting up FileVault 1 on a fresh macOS system.

This is a pretty severe change, so be very careful and have multiple backups of your system and user folders ready to restore if anything goes wrong.

Replace jason in the example with your user name as configured for your system and Jason Bourne with your real name.

dscl . -create /Users/jason
dscl . -create /Users/jason UserShell /bin/bash
dscl . -create /Users/jason RealName "Jason Bourne"
dscl . -create /Users/jason UniqueID 503
dscl . -create /Users/jason PrimaryGroupID 20
dscl . -create /Users/jason HomeDirectory "<home_dir><url>file://localhost/Users/jason/jason.sparsebundle</url></home_dir>"
dscl . -create /Users/jason NFSHomeDirectory /Users/jason
dscl . -passwd /Users/jason "apple"
mkdir /Users/jason
hdiutil create -quiet -encryption AES-256 -volname jason -certificate /Library/Keychains/FileVaultMaster.cer -fs JHFS+ /Users/jason/jason.sparsebundle -passphrase "apple"
chown -R jason:staff /Users/jason
chmod -R 500 /Users/jason
mv /Users/jason /Users/.jason
hdiutil attach -quiet -owners on /Users/.jason/jason.sparsebundle -mountroot /Users/ -nobrowse -passphrase "apple"
ditto "/System/Library/User Template/English.lproj/" /Users/jason
defaults write /Users/jason/Library/Preferences/.GlobalPreferences SuppressLegacyFVAlert 1
chown -R jason:staff /Users/jason
hdiutil detach -quiet /Users/jason
mv /Users/.jason /Users/jason

If you already have an encrypted folder, you may retain it for a user when upgrading your OS by using a different user to upgrade macOS so that legacy FileVault cannot be removed automatically if I remember correctly.

In theory, Apple's latest file system APFS, which became standard for SSDd in macOS High Sierra, supports multi-key encryption in the sense that you could use different keys for different users, though this is not reflected in the user interface of FileVault with APFS.