The break_machine function in MacDestroyer's postinstall does not work properly on an un-encrypted Mac running OS X El Capitan

[rtrouton]

The break_machine function in MacDestroyer's postinstall does not work properly on an un-encrypted Mac running OS X El Capitan. SIP will prevent any changes to /sbin/launchd

https://github.com/google/macops/blob/master/macdestroyer/postinstall#L66-L68

[russellhancox]

Good spot. We've never noticed as our machines are encrypted and the break_machine function was only ever a 'just-in-case' kind of thing.

Unfortunately, I can't think of a good alternative for 10.11.

[howiekaye]

A launchdaemon that puts a full screen window in front of the loginwindow?

On Tue, Mar 8, 2016 at 4:19 PM, Russell Hancox notifications@github.com
wrote:

Good spot. We've never noticed as our machines are encrypted and the
break_machine function was only ever a 'just-in-case' kind of thing.

Unfortunately, I can't think of a good alternative for 10.11.

—
Reply to this email directly or view it on GitHub
#55 (comment).

[jbaker10]

I don't think there would be a good way to randomize the password unfortunately, but you could send a command to set a Firmware password and use the security mode full which means the password is required for every boot, not just alternative disk/method boots.

So you could mount the Recovery HD, or include the Firmware Password Utility in a package, then use the command line to run:
setregproptool -p PASSWORD -m full

Again, this isn't ideal because you'd have to pass in a cleartext password, and you couldn't generate the random password locally (could however script the password that is going to be sent to be generated and stored somewhere before running it on the machine).

This has not been tested, just a proof of concept.

[jbaker10]

I take back my previous comment... I guess you could run the random password generator locally and have it sent to a server or email somewhere from within the script, all running on the machine that is about to be locked down. Had to think that one through ;)

[jbaker10]

Welp... I can confirm that this works on a 10.11 machine... Make sure you escrow the key somehow first though, otherwise you're left with a very locked machine... Whoops.

Here is what I added to the script for testing:

## Added the below variables where the LOCK_X values are
RECOVERY_HD="/dev/disk0s3"
BASE_SYSTEM="/Volumes/Recovery HD/com.apple.recovery.boot/BaseSystem.dmg"
FIRMWARE_UTILITY="/Volumes/OS X Base System/Applications/Utilities/Firmware Password Utility.app"

function lock_firmware() {
  /usr/sbin/diskutil quiet mount ${RECOVERY_HD}
  /usr/bin/hdiutil attach -quiet -nobrowse "${BASE_SYSTEM}"
  "${FIRMWARE_UTILITY}"/Contents/Resources/setregproptool -p ${LOCK_USER_PASSW} -m full
}

Then you just call the lock_firmware function in your main. Obviously this would need a few more conditions to ensure the machine supports Firmware passwords as there are a few systems that can run 10.11 but don't.