Question:
In the session yesterday, it was mentioned that Gatekeeper's app relocation moved the app on an unsigned disk image to a randomized place on the filesystem. How does this work?
Answer:
When the app with the unsigned dependencies is launched, Gatekeeper makes a synthetic instance of the app at a randomized location elsewhere in the filesystem. The synthesized instance of the app is what is actually being launched.
The synthesized instance is by itself in this new location, so it's unable to access the unsigned code / library / script, etc when it launches.
The synthesized instance is not a copy of the app. Overall behavior is similar to nullfs on BSD, or using bind mounts on Linux.
Question:
Are there any new features in System Integrity Protection on Sierra, or will the functionality be the same as in El Capitan? If there are new features, what are they?
Answer:
Same functionality as in El Capitan.
Question:
Are there new restrictions in System Integrity Protection on Sierra, or do the restrictions currently match those on El Capitan? If there are new restrictions, what are they?
Answer:
Same functionality as in El Capitan.
Question:
Are there any planned changes to how FileVault 2 works in Sierra on HFS+ volumes, or will the functionality be the same as in El Capitan? If there are new features, what are they?
Answer:
Same capabilities as El Capitan. No new features.
Question:
Are there any new features in the fdesetup command line tool on Sierra, or will the functionality be the same as in El Capitan? If there are new features, what are they?
Answer:
Check fdesetup man page for changes.
Follow-up Note:
I diff'd the fdesetup man page for macOS Sierra DP1 against the fdesetup man page for El Capitan 10.11.5 and found the following changes:
list verb for fdesetup - documented options changed to [--extended] [--offline] [--verbose]. In 10.115's manpage, they are listed as [-extended] [--offline] [-verbose]. This appears to be fixing typos, as opposed to the actual options changing.
This paragraph changed:
El Capitan:
"Care should be taken with passwords that may be used within files. For example, if you are scripting and need to securely remove a file, you should use 'srm' instead of 'rm'. Other precautions should be taken in your scripts to try to pass plist data directly from one tool to another to avoid writing this information to a persistent location."
Sierra:
"Care should be taken with passwords that may be used within files. Pre-cautions should be taken in your scripts to try to pass plist data directly from one tool to another to avoid writing this information to a persistent location."
Changed error codes in Sierra's fdesetup man page:
Error 25 - now reads "Unable to remove user or disable FileVault."
New error codes in Sierra's fdesetup man page:
- Error 30 - Unable to add user to FileVault because user record could not be found.
- Error 31 - Unable to enable FileVault due to management settings.
No other changes were found in the fdesetup man page. My assumption from this is that fdesetup does not currently have new features in macOS Sierra DP1.
Question:
When changing account passwords outside of the login window or System Preferences, it does not appear that the FileVault 2 pre-boot login screen gets updated with the new password information. Is there a way to force the OS to update the pre-boot login screen with the new password info?
The workaround that was provided for El Capitan was that, after the password change, it may be necessary to need to remove and add user with fdesetup. This will flush the old password's derived key and set up a derived key for the new password. Is this still the only workaround?
Answer:
May have same behavior as El Capitan. Test and file a bug if still broken.
Question:
Is fdesetup going to be the tool for interacting with APFS encryption, or will there be a new command line tool for managing APFS encryption? If there's a new tool, what is it?
Answer:
Still to be determined. File bugs and request the needed capabilities.
Question:
Will the per-file encryption / per-metadata encryption / per-extant encryption mechanisms each need their own recovery key?
Answer:
The recovery key model is currently planned to be similar to what is used in El Capitan, where there will be a system-level recovery key as opposed to multiple recovery keys.
Question:
Can APFS recovery key(s) be escrowed when enabling encryption? The goal is to store the recovery key(s) somewhere for later recovery by the company / institution which is managing the encrypted machine.
Answer:
The recovery key escrow model is currently planned to be similar to El Capitan. Details still being worked out.
Question:
How closely will the the unlocking mechanism and escrowing of encrypted APFS emulate what we have today in FileVault 2?
Answer:
The recovery model is currently planned to be similar to El Capitan. Details still being worked out.
Question:
On a Mac with encrypted APFS, are we still getting the same EFI-based FileVault 2 unlock screen at boot up?
Answer:
Great question! To be determined.
See complete list of session and lab notes here:
