
Secure Boot and the 2018 MacBook Pro - ArmandGrillet
http://michaellynn.github.io/2018/07/27/booting-secure/
======
userbinator
Summed up in one word: Scary.

Maybe Apple users are not as concerned about being able to run other OSs, but
there was a huge uproar a few years ago when secure boot was first introduced
to PCs. Fortunately you can still turn it off, but its removal may be
associated with an ostensibly compelling argument: "why would you not want
security?" The answer to that can also be summed up in one word: freedom.

~~~
noja
I don't know why you are being downvoted: losing the ability to install what
we want on our computers is clearly A Bad Thing.

~~~
epistasis
I don't understand what either of your comments have to do with the article.
You seem to be assuming some counterfactual implementation of the feature, but
the article is quite explicit that these fears are unfounded. There is no loss
of the ability to install what you want.

~~~
IntelMiner
It puts mechanisms in place to deny that in future, however

------
shiburizu
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.

~~~
CGamesPlay
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.

~~~
antoncohen
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.

~~~
CodeWriter23
> 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.

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

------
avhwl
Cool write-up. This is one of the things that interested me about the new T2
computers; having a secure boot process that loads every link in the boot
chain using cryptographic signatures verified by an onboard TPM engineered by
some of the smartest people in hardware security. This isn't a move by Apple
to lock users into their platform, they do that far more effectively through
other means.

~~~
saagarjha
It really looks like a boot verification process to restrict which OSes can
run on the device, à la iOS, which can only run what is current and signed by
Apple.

------
saagarjha
Looks like Apple's implemented a significant part of the iOS boot chain
security model here: I'm seeing AP Tickets, the Tatsu Signing Server
(gs.apple.com), and personalization using ECIDs, all of which are part of the
signing process for low-level boot on iOS.

By the way, the iPhone Wiki has J137AP down as the iBridge processor, not the
iMac Pro itself:
[https://www.theiphonewiki.com/wiki/J137AP](https://www.theiphonewiki.com/wiki/J137AP)

------
josteink
Mods: Title could be amended to mention that this is about imaging solutions
for new Macs with Secure boot.

~~~
lucb1e
Agree, but maybe the word provisioning is better. I initially interpreted the
title as being about booting other OSes from Apple hardware, or perhaps a vuln
in their secure boot firmware, but not about provisioning Apple hardware by
booting from USB or something.

~~~
brazzledazzle
The security implications and what you do and don’t get out of it from a
security perspective are discussed. Like you can drop a launchdaemon on it and
that’s not evaluated as part of the system’s integrity. Only the boot process
(for now).

~~~
saagarjha
How would you drop a Launch Daemon on the device if FileVault is enabled (as
it is by default on all new Macs)?

~~~
brazzledazzle
You couldn’t disable it and reenable it?

~~~
saagarjha
You'd need the disk password to do that.

~~~
brazzledazzle
I think there’s a misunderstanding here. He’s talking about modification of
the Mac between Apple and the customer. I thought you were saying it’s pre-
encrypted, my fault for misunderstanding.

------
tpurves
Ah. Does this explain why my IT department has frozen all new Mac
distributions for the next 6 months because of the T2 chip?

------
amerine
Thanks for the wonderful write-up.

------
abalone
Has anyone heard any more details on how GreyKey bypasses secure boot on the
iPhone? Do we know the T2 has fixed that flaw?

------
vondur
There is a command you can run that will allow you to boot and do the restore
from Apple. But you definitely need a fast internet connection. If you manage
Mac’s you are going to have to sign up for DEP and something like JAMF.

------
21
It's simple.

When SecureBoot is done by Microsoft, it's a terrible thing that destroys all
freedoms. All hardware with it should be boycotted.

When it's done by Apple, it's a nice security feature, what's your problem?

~~~
beagle3
Can you link to the instructions for disabling SecureBoot on microsoft ARM
devices?

~~~
geofft
Same place as the instructions for disabling Secure Boot on Apple ARM devices.

These corporations are big enough that it makes little sense to say
"corporation good" or "corporation bad" (and it also doesn't provide any
incentive for the corporation to change). If we say "Enforced bootloader
signature verification with the ability for the physical device owner to
enroll keys is good" and "Enforced bootloader signature verification without
that is bad," that applies equally well to both MS and Apple.

~~~
beagle3
I tend to agree about "feature good, feature bad".

But corporations ("are people" and) it definitely makes sense to say they are
"good" or "bad", just as you can say that about people.

Microsoft, for decades, bullied everyone around and kept pissing into the
collective village well, e.g. with their stacking of ISO committees towards
standardizing OOXML, which later slowed down ISO processes to a stop because
of the many never-present-never-voting-except-that-one-vote members (and those
processes are not quick to begin with). I have over 20 years of bullying
stories between 1990-2010 or so, some of which I was personally involved and
affected by.

They have been beat into submission in the last few years, and are now
behaving in line with a "good corporate citizen" behaviour. If they continue
that for twenty years, I might consider them reformed.

Holywood/MPAA are a "bad corporation" for their work on the public domain.
Oracle are a "bad corporation" for anyone who likes open systems. Google is a
"bad corporation" for anyone who likes privacy. Facebook is a "bad
corporation" for almost any group. I'm sure Apple is too, but I haven't met
anyone who has been affected by Apple's policies except of being a direct
competitor, so I'm not sure how that group looks.

All of these companies do deliver useful services, of course. But they do that
for profit (which is what a corporate does). And while doing that, to grow,
they inflict great harm on the ecosystem at large, much larger than the
benefit and profit they derive from causing that harm. I guess that's one
definition of a "bad actor" in my book.

