Hacker News Reader

Comment by shiburizu | Hacker News Reader

What I don't get is this: If Apple wants to introduce "Secure Boot" while also pitching their products to "creative professionals" (who most surely run to their IT departments to pick up their MacBooks fresh off a purchase order) would they really overlook an imaging solution? Surely being the kings of walled garden ecosystem could spin this up in their own solution.

View on HN

The motivation to prevent imaging is that an attacker can modify the device before it gets to the end user. With MDM, the IT department can audit all of the changes that have been applied post-Apple. And the IT department can use it to apply whatever changes they want to. So the gist of it is it’s “more secure than imaging”. My understanding is that the community hasn’t figured out how to do everything they need to with just MDM/DEP, so some imaging use cases still exist, and the community hasn’t figured out how to apply the MDM/DEP workflows to as many machines as quickly as the imaging workflow.

It sounds to me like imaging is the solution to attackers modifying systems during shipment.

> Are you someone that needs to worry that a delivered device has been manipulated mid-shipment?

> If you try placing a simple LaunchDaemon on a Secure Boot device’s System volume, it doesn’t stop it from booting in Full Security mode. That’s not one of the things in the signature manifest.

With DEP/MDM the existing OS and files that were there doing shipment would still be there, DEP/MDM would just add additional things or change settings. With imaging you wipe out everything that was there during shipment and start fresh.

> It sounds to me like imaging is the solution to attackers modifying systems during shipment.

It’s not. They could hack the BIOS or the IME to establish a rootkit that is practically impossible to detect.

Then why is the effort not to detect/reinitialize modifications to the BIOS or IME instead of this more complicated alternative?

The "secure" part of secure boot only protects booting macOS, it doesn't safeguard against actors intercepting shipments and dropping malware before the customer performs MDM setup via DEP. E.g. it's trivial to sideload a LaunchDaemon via Target Disk Mode, which the Mac will load on first boot, even with full protection, since FileVault hasn't yet been enabled by the user (or the MDM). Imaging every device that you buy is still the only available protection against this threat. Note that Secure Boot is very much a welcome feature in this scenario, as it also secures the machine's firmware.

Performance is also a factor, as you mention. If you're onboarding hundreds of people in the same room at the same time, there's no WiFi in the world that can deliver the base config in a timely and reliable manner. One solution is to preload all the necessary bits, see for example Facebook's AutoDMG Cache Builder.

Imaging is still also by far the most automatable solution, and the only one that can truly be zero touch. It's possible to reinstall and set up a fleet of machines, with no human needed to touch them. DEP still requires a human with physical access to set up the machine on first boot.

While we've switched to DEP and MDM as our main deployment method, it still has a ways to go before it covers all cases.

Which is great, except when the attackers use MDM to compromise your system

https://arstechnica.com/information-technology/2018/07/hyper...

It sounds like they're pitching for the DEP setup instead. DEP, in combination with post-deploy tools, provides another way to handle device provisioning.

It’s barely workable once you hit a few thousand machines. That being said, most people don’t end up in that situation. Any large company doing IOS CI with 100+ developers however will encounter issues with the demise of network booting/imaging.

If you're an enterprise-ish company, you use DEP which they still support. This only affects companies that have, for whatever reason, chose not to use the solution Apple provides for this.

Reply on news.ycombinator.com