Secure Boot and the 2018 MacBook Pro
michaellynn.github.io
michaellynn.github.io
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.
As an individual, the freedom to install whatever OS you want is important.
As a company, you want to have the option to bootstrap the software from a cryptographically signed image so that group policies, etc. can all be enforced in one long, auditable chain starting from the onboard TPM. While most employees might not need that, something like that is useful for making sure remote datacenter access is secure.
Not saying that there aren't companies for which this is desirable. Such companies exist. What I am saying is that their reasoning is bullshit and has more to do with some people keeping their jobs, so it's job security instead of actual security.
I'm a proponent of proportional amounts of paranoia. Restricting everyone is disproportional. Preventing developers from installing software on their dev boxes probably does more harm than good.
On the other hand, putting tight controls on computers people use for admin access to servers is not a bad idea if your company is big enough that only the dev ops guys really need to be in there with real regularity, or if your company handles sensitive data. Then the practical layer of security might be worthwhile to make getting into the datacenter via a compromised engineer or dev box harder.
That's the scenario I'm familiar with: secure boot on a separate machine, and a tight lid on what software you can put on the system, in order to guarantee a baseline level of hygiene for any system that talks directly with the datacenter.
There's an incentive to disallow unauthorized software from running on your hardware platform: it forces users to go through approved channels for their software and data. If you own an App Store and services like iTunes, the financial incentives exist to ensure your users don't sideload content or use competing app/media markets.
...for now. The frog boils very slowly.
This reasoning is overused and wrong.
Apple's hardware is no good for other operating systems, it doesn't run well with either Linux or Windows, the support being shitty due to Apple's proprietary stuff. As an example the experience with the touchpad becomes much poorer and the battery life is reduced to about half.
Running Windows or Linux well puts Apple in the commodity hardware market and that's what they tried to avoid ever since Steve Jobs came back.
So as a matter of fact they do sell MacOS as a core part of the package and they don't intend for it to be replaceable. Just like they sell iOS. It's not like you can install another operating system on their iPhones and iPads. Those devices don't even belong to consumers that bought them actually. All you're getting is a license to use them.
Apple is definitely not in the hardware business. What they sell is licenses.
Ahhm. BootCamp[0] is an integral part of MacOS for a while. (and before that, for a couple of years, it was a free add-on). It is the apple mandated, supported, sanctioned way to run Windows on a Mac, including needed drivers. Battery life is not quite as good, true.
Your claim that "Apple is definitely not in the hardware business. What they sell is licenses." is contradicted, both by the existence of BootCamp, and by your inability to buy a license without the hardware (and/or at a price that does not include a profit premium on that hardware).
And Bootcamp is nothing more than smoke and mirrors, a checkbox to tick in order for apologists to have amo.
Having used Windows on a MacBook Pro 2016 for two years, my experience has been worse than with a commodity Levono at 1/4 the price.
Given that you were running Windows on your Mac, I gather that your argument is more one related to the licensing issues of running macOS on non-Apple hardware, rather than an argument that it isn't technically possible. In any case, there is this. Curious how the project will be impacted by these new changes. From the article, it seems that in No Security mode the bootloader may be modifiable in the ways that it needs to be for modifications like Clover to work.
Clover EFI bootloader https://sourceforge.net/projects/cloverefiboot/
Features
Boot OS X, Windows, and Linux in UEFI or legacy mode on Mac or PC with UEFI or BIOS firmware
Boot using UEFI firmware directly or CloverEFI UEFI firmware emulation
However, could you elaborate on why the fact that you cannot buy an OSX license proves your point that Apple is in the business of selling licenses? I am at loss.
It would be weird if a dev preferred the lockdown, and weirder still if my grandmother didn’t.
I am much more careful about what gets downloaded on my computer but I want to be able to do anything.
I’m a Dev and I prefer the lockdown, on my daily driver device that is. If it was forced on every device, I’d be opposed, but having it be something I can opt out of on my dev devices is perfect IMHO.
Disclaimer: I worked on this.
…which I don't believe Apple has opened up? Right now it's use Apple's keys for verification, or don't use the feature at all.
If word gets out to every shady character that stolen macbooks are effectively bricks, perfect.
(Note that untrustworthy drive firmware has an easy workaround at least in theory - just do full-disk authenticated encryption, and then the drive can't do anything worse than DoS you, which is sort of a thing drives tend to do on their own anyway.)
I work on OneCore (Windows) and sometimes I have trouble believing the kind of crap some hardware vendors ship as firmware.
Incidentally, an interesting defense against evil maid attacks involves glitter nail polish. Use it on a sticker over the case and take a photo. To verify your laptop is safe, compare the sticker with the photo. The key is that glitter polish has a lot of minute detail and is thus hard to replicate.
This only gives tamper protection, but evil maid attacks require interaction so it suffices for security.
So, no, the whole secure boot thing is just bullshit security theater and more lock in.
> So, no, the whole secure boot thing is just bullshit security theater and more lock in.
Only if you're only thinking about laptops, desktops, maybe phones and tablets. There are lots of types of machines out there physically exposed to users whom the machine-owners trust to varying degrees, ranging from "not at all" on up.
Think UPS package scanners, HVAC systems, various control systems in everything from warehouses to prisons, sensors and signage controls...
Now, Secure Boot doesn't address anywhere near anything close to "sufficient" in any of those environments, but it is one component of raising the costs of attacking them to a point to make the systems economically viable, or at least apparently so.
If someone disables SecureBoot, then the encryption keys become inaccessible and you will notice that something is wrong.
I don't quite understand your wipe the disk thing, since that will leave a trace, the attacker could just smash your computer or take out your drives.
Combined with a TPU that wipes keys when secure boot is enabled/disabled gives a pretty secure system, that still allows you to "eject" to an unsigned boot when needed.
I'm not sure how this would work on Apple devices. It seems to me they have reinvented the whole security infrastructure of their services, which it's not a bad thing, but also requires some serious hacking if you don't want your device locked down with Apple-only software. Is there any way you could possibly manage the trust chain of secure boot on devices with the T2?
I guess "Reboot into Recovery, Open the Secure Startup Utility and allow booting from external media and Set it to No Security" counts as serious hacking now :)
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.
> 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’s not. They could hack the BIOS or the IME to establish a rootkit that is practically impossible to detect.
https://arstechnica.com/information-technology/2018/07/hyper...
By the way, the iPhone Wiki has J137AP down as the iBridge processor, not the iMac Pro itself: https://www.theiphonewiki.com/wiki/J137AP
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?
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.
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.
Microsoft's restrictions here are abhorrent, but they're also not outside the industry norms. The "Windows ARM devices must enforce secure boot" thing dates to the only Windows ARM devices being phones and tablets, and it's been updated now that that's changing.
The discussion in https://news.ycombinator.com/item?id=15855195 indicates that, as of 7 months ago, this was not the case if those laptop-style ARM devices (the linked policy on microsoft's website is now 404).
> The "Windows ARM devices must enforce secure boot" thing dates to the only Windows ARM devices being phones and tablets, and it's been updated now that that's changing.
It included Surface RT with keyboards, which were esentially laptop-style, at the point in time where Microsoft was still expecting other manufacturers to adopt RT (IIRC there were even a couple of samsung laptop models, quickly dropped).
Just look at amount of comments on Apple threads concerning their eager assistance to Chinese regime and amount of comments declaring Apple hardware as the second coming of the messiah in all other hardware threads.