> Apple should be lauded for trying to bring their laptop and desktop lines into the same defensive posture as their mobile offerings.
I think this can't be stated enough. The fact of the matter is that pre T2, evil maid attacks were ridiculously easy. Now they're at least as secure as iOS -- which also means that shared vulnerabilities can be patched and detected. By no means is it perfect security, but it's a heck of a lot better than "stick boot disk in and gain keys to the kingdom."
For so long we've gone by the mantra that physical access means you have root. Now we're a step ahead of that -- which is great for data privacy.
...and absolutely horrible for freedom. It used to be the case, and still widely accepted for a lot of other products, that physical ownership actually meant something beyond just being a consumer. Now companies are turning the security against users, lest they also be attackers. From the point of view of the DRM-advocating media corporations, the user is an attacker. Locking down the platform to allow only "trusted" (not by you, but by them!) code only benefits when their goals align with yours; you may agree with them on not wanting things like ransomware, but not on things like them not allowing you to share a file between two apps or even run code you wrote yourself.
It's scarier than any security attack to see what used to be an open and free platform turned into a walled garden of corporate control and obedience.
> It used to be the case, and still widely accepted for a lot of other products, that physical ownership actually meant something beyond just being a consumer.
It still does. The only thing is we've distinguished physical ownership and mere physical possession.
It is a feature that if I leave my personal laptop at my desk at work while using the bathroom, my IT department can't rootkit it. It is an improvement to my freedom - both my computing freedom and my physical freedom - if I can leave a laptop in my hotel room while seeing tourist sights. It protects me from the government if a border control agent looking through my bag, or a cop who's seized my laptop, can't get in. (The iPhone is an existence proof that such defense against the government is possible, and it's weird that the usually pro-personal-liberty free software crowd hasn't decided that a free software implementation of the same thing is critically important.)
Of course software freedom requires access control. My freedom over my possessions involves other people's lack of freedom over my possessions. I can't make sure my computer is running the code I want it to if everyone else can make my computer run the code they want it to. This control is essential liberty; pretending that anyone with physical access is an owner because it's easier than crypto and key management has been decades of temporary convenience, and I'm glad it's coming to an end.
I can turn secure boot on and off with an admin password, which I set when I first booted the machine because that's what demonstrates physical ownership and not mere possession. (And systems that don't permit me to do so, like Microsoft or Apple ARM devices, are in fact an affront to software freedom.) But nobody else can.
You can turn it on or off, but if you want to do anything on your own you have to turn it off as your can't sign anything. If they were really giving you what you say they should make signing your own apps as easy as turning it on/off.
This can't be stressed enough. Freedom (indeed "ownership") means that I should be able to run any app I want on my device without having to create an account with Apple. It would be great if I could have both freedom and security, but Apple has decided that is not an option. I have to choose one or the other.
That's literally what I said. There's a checkbox for you to choose freedom inside System Preferences. You, as a device owner, can check that box. Someone with temporary access to your computer cannot.
This is a step forward for most users and not a step backwards for any users. Sure, it would be better to let you enroll your own keys. But as it is you have more options than you have previously, and you as device owner are the only person who can decide between those options - attackers have no more options than they had previously.
With UEFI Secure Boot, you can enroll your own "Machine Owner Key" and use the private part for signing, thus having both, freedom and to a certain degree security (the hardware has firmware, that with high degree of probability won't be signed by your key, so you will have to keep someone else key enrolled too; so it is not perfect either).
Platforms like T2, which allow only on/off, but not key enrollments, are a step back.
I can't argue with the notion that this adds an option for users, and increases the security of users who choose to use the functionality.
I can't help but think that you're suffering from some kind of IT Stockholm Syndrome, however. Characterizing a secure boot option that only allows MacOS to be booted securely, (with no option to enroll your own keys) as "freedom" sounds to me like characterizing the 2002 Iraqi presidential referendum as a "free election".
Apple's agenda isn't aligned with user freedom. There's no place for the word "freedom" in characterizing Apple. They arguably have a user security and privacy agenda, but they have no user freedom agenda.
Without T2: You don't have the option of booting anything securely.
With T2: You can boot macOS securely, but everything else is still insecure.
If Apple had denied the option to disable secure boot, and didn't make any affordances to boot other OSes (albeit insecurely), we would indeed have lost freedom. The way they did it, we gained security within the macOS ecosystem without losing any freedom elsewhere.
I'm not characterizing the presence of the switch as freedom - I'm characterizing the existence of the choice "Do things the old way" as containing as much freedom as you previously had, and pointing out that a) such a choice exists b) the ability to make the choice is in the hands of the owner only.
You can't meaningfully characterize the 2002 Iraqi election as a loss of freedom. You can characterize it as a farce, sure. You can call it evidence that you had no freedom all along. (And if people want to say that the lack of user-enrolled secure boot has been a freedom problem with personal computers since forever, I will certainly agree with them.) But you can't meaningfully say, "We had more freedom before this election, and I want to go back to how things were." So arguments about giving up essential liberty and temporary safety just don't technically make sense. If you don't have essential liberty now, you certainly didn't have it before.
I also think that there will be some users who will choose freely to use macOS because they genuinely believe that's better for their computing freedom, and they're not manifestly wrong in reaching that conclusion (whereas I would be much more skeptical of someone saying "I voted for Saddam because I think he's going to do good things for the country"). As I mentioned there is no competent free software implementation of an OS secure against evil maid attacks, with secure boot and TPM-locked full disk encryption. You can, in theory, fiddle with tpm-tools and cryptsetup and shim (or coreboot?) and build something of your own; I've never seen anyone do it, and I've certainly not seen a distro that provides a one-click option in the installer to do it. macOS on a system with a T2 chip provides this out of the box. Windows with BitLocker does. Chrome OS does. (I suppose Chromium OS does, but doing binary builds of that seems at least as tricky as getting cryptsetup and tpm-tools working.) A user who decides to use a proprietary platform as a tradeoff for knowing that their machine is only running software they've chosen (even though their choices are limited) is not obviously making a mistake.
(I will admit that I have a Chromebook for secure stuff and a normal Debian stable laptop for everyday stuff, and I am considering the purchase of a Mac with a T2 chip, for roughly these reasons. I've wanted to figure out TrouSerS / tpm-tools for years but at this point it's clear I won't get around to it.)
> This is a step forward for most users and not a step backwards for any users.
Maybe. What happens when the check box goes away on a future version of MacOS? If my freedom depends entirely on an obscure checkbox rather than the ability to install my own keys, that seems like a thin reed to me.
That depends on how that option is deployed and how it interacts with the hardware. It is at least possible to deploy a key-based option that Apple could not arbitrarily rescind. It's not possible to do that with a check box in a control panel.
Even if you turn secure boot off you cannot grant for love or any amount of money permission for software of your choosing to access the built in storage which is pretty much required for normal people to be able to run software of their choosing on the machine.
Few people will buy equivalent external ssd storage for 300-500 and carry it around with them to have access to a second OS.
There is absolutely no reason to believe that they will ever act to increase your ownership of your own device and every reason to believe that you will ultimately have about the same privileges as someone using their employers machine at work while being expected to fall full freight.
It's especially bemusing when you understand that evil maid is almost nonexistent in reality while your actual loss of freedom has real effects now.
What software of your choice have you attempted to use, where did it fail, and what's the stack trace?
Given that Windows works, it's hard to believe that any issues accessing internal storage are a result of permissions. It just sounds like nobody's implemented Linux support for the hardware. Why don't you?
If you're not able to either spend time writing a driver or hiring someone to do so, you have no meaningful ability to exercise your software freedom. You might be lucky if someone else implements support; you might not. But that's always been true.
Windows works on the new MacBook not because it has special drivers for NVMe-via-T2 but because Apple trusts Microsoft's EFI key.
So no, stop it with all this "Linux works if you just disable Secure Boot" nonsense. It doesn't. You can run Linux from a USB key, sure, but it can't access the internal NVMe SSD!
It looks like some kind of driver issue, not an intentional lockout.
To corroborate this, while I don’t have personal experience running Linux on T2 devices, I do know it’s possible to build xnu from source and boot the resulting unsigned kernel (in “No Security” mode) without the disk disappearing.
Please provide evidence for this causal link. It is true that (with Boot Camp enabled) the firmware trusts the Windows key and not the MS third-party key. It is true that Windows can access the disk and Linux cannot. It is not obvious that these are related.
Why don't I in my free time implement driver support for a machine I can't afford for a company with almost 300 billion in cash equivalents who has benefited massively from open source but wont even provide specification so that someone can do the free work for them effectively?
Why don't they send me a laptop along with the specs one of their engineers feels sufficient to implement support?
I believe they are referring to the fact that linux (and non boot camp windows) cannot access the SSD on T2 equiped macbooks. People seem to disagree if it's the T2 itself or just a driver issue with apples proprietary controller.
Nobody ever said you can't disable secure boot and boot from an external drive. The point is that you can't access the expensive and essential internal storage where all your data lives. Here is an equivalent product a thunderbolt external nvme ssd 480GB for about $300.
If you don't mind spending hundreds of dollars, carrying around a second slightly awkward box wherein if you accidentally unplug it your computer crashes, and if you continue to use osx ferrying data between a and b periodically you too can run linux.
It would be utterly fantastic if people didn't keep responding to reports of the actual problem with articles like this which actually don't even touch on the item at hand.
People are responding this way because there are contradictory reports out there. Some sources, like the one I linked to and Apple's T2 security document, say you can run Linux without mentioning that you need an external drive. Have you tried disabling security as Apple suggests and installing Linux?
There seem to be several individuals making the claim that you can boot linux if you disable secure boot I have heard zero people claim that linux can access the internal device.
As far as I can see all primary sources are saying the same things. Then people who don't have the hardware are misreading said reports and spreading misinformation.
I don't have the hardware either so I can give you no direct report myself. I just bothered to read what people are saying instead of skimming and guessing.
> I can't make sure my computer is running the code I want it to if everyone else can make my computer run the code they want it to
This is exactly why _you_ must be in control of what software can boot and not Apple or some other company. It's not exactly freedom if you must disable the secure boot feature to run your own software, it's a work-around.
If Apple really cared about freedom they would provide you with your own _unique_ key to sign your own software, so you can ensure that your system actually runs _your_ software.
>and it's weird that the usually pro-personal-liberty free software crowd hasn't decided that a free software implementation of the same thing is critically important.)
Purism did. But this requires hardware too which the free software people don't have access to.
> Now companies are turning the security against users, lest they also be attackers.
This has always been the case, has it not? Modern security practices seem to operate under the assumption that the attacker can do almost anything the user can except sniff the password out of the user's head.
I think that's a reasonable model to work under. Building a platform that makes it a near-guarantee that the only way to unlock a computer is to be in the user's brain is a commendable security model, and the fact that Apple is executing it so seamlessly (i.e. with minimal user interaction) is honestly incredible. Gone are the days when you need to jump through hoops for security. It's democratized and available to everyone.
I would say that this is amazing for freedom. You could ask for little more than for every citizen to have state-of-the-art security.
---
Of course, vote with your wallet. If you don't like DRM content, don't get it. If you like the T2 chip and need a new laptop, get a Mac. No one is depriving you of choice, here.
They even go beyond the assumption of sniffing passwords from users head on the iPhone.
Thanks to the face/fingerprint reader, most people are incapable of divulging their pin/password to someone claiming to be the county password inspector.
While in an absolute/legal sense it’s less secure, for day to day use by most people it’s more secure as there is no password for someone to watch you enter, or socialy compel you to give them.
> Don't know about face id, but with finger ID you certainly need to know the pin number for all the cases that finger ID doesn't work.
This is the case with Face ID as well. I use my PIN more with Face ID than I did with Touch ID.
> More than that, it's easier for a security guard to point the phone at your face / push your thumb on the sensor than get you to reveal a passcode
It's fairly easy to discreetly disable, FWIW. Just "squeeze" your phone for two seconds (i.e. press the power button and either volume button) to disable Face ID. It also won't work if you're looking away or have your eyes closed.
They provide a setting that lets you disable the boot security at will, allowing you to install Linux or any other alternative OS. Security features on macOS (as opposed to iOS) are generally optional, but enabled by default (as is the sensible choice).
They don’t provide you the ability to reprogram the T2 itself, which is a shame but not entirely without merit - compromising the T2 chip would be far more dangerous than compromising the OS in terms of persistence.
I've read that the T2 chip also provides the mass storage interface and without documentation or drivers, Linux cannot be run from the internal drive. Devices with the T2 chip can be booted and run from USB connections with the security disabled but not an internal drive.
Yes, that's unfortunate - the lack of drivers means that Linux devs will once again have to reverse someone's proprietary software to develop their own drivers. It's not a fun state of affairs. Unfortunately, Apple is not likely to start fully supporting Linux on Mac hardware by providing drivers and documentation. But the point here is that they haven't done anything technically to prevent you from running Linux.
Unacceptable. The user must disable Secure Boot to run Linux, which means the system becomes vulnerable to bootkit attacks. And, the typical scenario will be a user who leaves it disabled, making both macOS and Linux and possibly Windows (if also installed) more vulnerable to bootkit attacks.
I'm quite sure Microsoft would be willing to provide Apple their UEFI public key, which is what pretty much all Linux shim bootloaders are signed with.
> Unacceptable. The user must disable Secure Boot to run Linux, which means the system becomes vulnerable to bootkit attacks.
I see this said a lot, and I find it baffling because so many Linux users demanded no secure boot at all - which is exactly the thing being called unacceptable now. (It's not just you; The Register, for instance, complained about how "malware or malicious users that gets onto your Mac can potentially alter the operating system to hide spyware right from startup" when secure boot is off, in an article otherwise complaining about how Apple must hate Linux users because secure boot is now on.) There is no increased risk of bootkit attacks to Linux users as a result of this change. There is simply a reduced risk to macOS users.
I do agree that a model (as MS implemented) where you can enroll your own keys would be better - but that would be a new feature. In the meantime, if every Macintosh from the 128K until today was acceptable, what changed?
The white paper addresses this - the UEFI CA is not included in the secure enclave's trust store. This is intentional - the UEFI CA is used to sign bootloaders that don't perform chain-of-trust validation, meaning that if the secure enclave trusted the UEFI CA by default, then secure boot could be pretty trivially bypassed.
Sure, they could make things more secure by allowing you to add your own keys. You could go ahead and add the public key for your secure bootloader that does chain-of-trust validation, but the "typical scenario" would be a user adding a generic UEFI CA that leaves them open to a modified or malicious OS.
> And, the typical scenario will be a user who leaves it disabled, making both macOS and Linux and possibly Windows (if also installed) more vulnerable to bootkit attacks.
No way. The typical user will leave it enabled because they will only use macOS.
So Apple will let you run macOS or Windows, but not Linux or anything else. Wow. This is the exact scenario the secure boot opponents several years ago were trying to stop.
"It's scarier than any security attack to see what used to be an open and free platform turned into a walled garden of corporate control and obedience."
Most users threat posture is around security from adversaries who may gain control of their hardware. That security helps preserve their freedom, to store secrets more safely on the device etc.
Users are generally much less concerned with their own ability to hack / boot an alternative OS etc.
I suspect very few companies other than Apple will even have a chance of standing up to big gov demands, and even Apple may cave (though they seemed willing to stick to principal even in case of known domestic terrorist shooter which is one of the toughest arguments to make).
If you need the freedom to be hacked and to hack your own hardware, consider an android or linux machine.
Yes because there aren’t users that are downloading web extensions that are malware, getting infected with ransomware, and programs that secretly mine crypto currency.
My mom was just looking for a printer driver (why are printer drivers even a thing on Windows in 2018?) and ended up with all kind of crap on her computer after going to the first site she saw on Google.
A friends mother told me that when she is on her computer she can see someone else controlling it remotely.
> I think this can't be stated enough. The fact of the matter is that pre T2, evil maid attacks were ridiculously easy.
Factually and objectively wrong.
This does nothing for end-user security which wasn’t already solved by UEFI Secure boot half a decade ago.
The only difference here is that Apple now insist on owning all the keys, taking away any aspect of end-user freedom which may have been present in the UEFI spec.
This is all bad, all regression for the PC-platform and Apple should definitely not be applauded.
> Factually and objectively wrong. This does nothing for end-user security which wasn’t already solved by UEFI Secure boot half a decade ago.
UEFI Secure Boot is a noop security-wise if you don't have a TPM to store keys and validate signatures, otherwise it's trivial to bypass. This whole thing implements UEFI Secure Boot, and T2 is the TPM.
Secure Boot can be disabled to install Linux, the only difference from before T2 was introduced on Macs being that Linux fails to initialise/access† internal storage behind T2. Using either a pre-signed loader with MOKs in NVRAM or your own signing keys is terribly involved[0][1] and adding keys or disabling SB is not always supported, even on PCs.
† For reasons yet unknown which could be any of a) bug in T2, b) lack of hardware support within Linux, c) intentional security measure, d) intentionally crippled feature. Judgement as to whether this is a glitch, undocumented hardware behaviour, or a mischievous scheme is currently impossible and an open question; stating anything one way or the other is currently based purely on personal beliefs, not facts.
> For so long we've gone by the mantra that physical access means you have root.
This hasn't been the case for a long time. Chromebooks shipped with "verified boot" since the first consumer hardware in 2011. Windows machines have been shipping with UEFI secure boot, which Apple uses the T2 chip to implement, for the past 6 years.
I'm also super excited that the entertainment industry has caught up as well. Before it was ridiculously easy to inject ads and objectionable content into my video streams but thanks to HDCP I never have to worry about that again. It's so much more secure!
> We believe the T2 platform is a leap forward in platform security in the Apple ecosystem, and it begins to bring exciting security properties like Secure Boot capabilities to the mass market.
So the vast PC-market with UEFI secure boot which predates this by 6 year was somehow not the “mass market”, but the relatively tiny MacBook market is?
With factual errors like this present already in the introduction, it’s hard to take anything which follows it seriously.
You are missing the bigger picture in your attempt to immediately discard the original articles premise because you feel like it comes off as fanboy-fluff.
No other device on the market currently provides a secondary processor that runs full validation of the UEFI firmware before allowing the processor to start booting.
It's not just secure boot, which has been around for a while, it's everything around it.
On almost all other devices you could write new data to a flash chip and that now becomes the UEFI boot loader that is used (and can bypass secure boot). There is no verification of the UEFI boatloader that is possible because it's sitting in NVRAM or Flash... and you can't trust it to self-verify because it may have been tampered with.
> On almost all other devices you could write new data to a flash chip and that now becomes the UEFI boot loader that is used (and can bypass secure boot).
Let me see if I understand you completely.
What you're saying that if an attacker is willing to physically dismantle the machine, he can then, using SPI-flasher HW, replace the UEFI firmware on the machine with a custom UEFI firmware which does not enforce secure-boot...
And thus the machine's security is compromised?
If so, let me just state my opinion: If that's the kind of attacker you are trying to protect against, no matter of security measures is going to keep you fully secure.
And if we're going down that lane: what prevents an attacker this sophisticated from doing the same with the T2-chip's firmware?
What Apple offers with the T2 chip, for most people, has almost zero value, while providing lots of drawbacks over traditional UEFI Secure Boot.
This is all about Apple extending their platform lock-in to no longer only apply to mobile and tablet-space, but also to their traditional computer-line of products.
There's nothing noble being done here. It's just a plain-in-sight money-grab.
> What you're saying that if an attacker is willing to physically dismantle the machine, he can then, using SPI-flasher HW, replace the UEFI firmware on the machine with a custom UEFI firmware which does not enforce secure-boot...
Yeah, that's kind of the classic evil maid attack, and it is not unheard of for various spy agencies to dismantle devices to gain access or install bugs.
> If that's the kind of attacker you are trying to protect against
That is exactly what the T2 chip is designed to protect against, and more.
The T2 chip also runs all of the encryption/decryption for the integrated storage, this way all data on the flash is encrypted at all times.
I can imagine that the T2 chip over time will be able to do much more to help provide extra verification and security to the device and help keep users safe.
> And if we're going down that lane: what prevents an attacker this sophisticated from doing the same with the T2-chip's firmware?
Because the firmware on the T2 chip is signed and the way the chip is designed the only way to get firmware on it is to decap it because it is stored internal to the chip itself.
With your stock standard x86 motherboard that is not the case because the firmware is loaded from an unencrypted and unverified flash chip.
> What Apple offers with the T2 chip, for most people, has almost zero value
We'll have to agree to disagree, because the T2 chip also does full line-rate encryption/decryption of the storage with no OS involvement at all. This means if your laptop falls in the wrong hands, now people can't get at the data even by reading directly from the flash chips.
----
You are the one that claimed that the article was fanboy-fluff, I just described a feature that no other machine has... and you immediately consider it a money-grab rather than something to laud Apple for. Yet SecureBoot is good enough? Why not keep improving upon the status quo? Why not make it easier for people to keep their data private and secure?
It's all about defense in depth, and Apple added one more depth to their platform.
So is pretty much all UEFI firmware too though. It may not be encrypted, but it is certainly verified. Feel free to ask the Coreboot people about details here.
> We'll have to agree to disagree, because the T2 chip also does full line-rate encryption/decryption of the storage with no OS involvement at all.
But for people who has been using BitLocker or LUKS transparently (because it's built into the OS) for half a decade+, there are absolutely zero new things offered, and no visible improvements offered.
The only effective change is restrictions in end-user freedom.
> Yet SecureBoot is good enough? Why not keep improving upon the status quo? Why not make it easier for people to keep their data private and secure?
If a security feature which can easily be implemented (securely) in the OS is moved to firmware, I could be willing to consider that a good thing, but not it comes at the cost of end-user freedom.
> That is exactly what the T2 chip is designed to protect against
The point the OP was making is that if your threat has the technical ability to dismantle down to the circuit level and rebuild then you've got bigger problems. Such as corporal or legal jeopardy.
They could just beat you with a rubber hose until you log in. Or throw you in jail for five years for contempt of court.
The classic 'evil maid' attack is more like script-kiddie threat compared to that, and Secure Boot was sufficient protection.
> No other device on the market currently provides a secondary processor that runs full validation of the UEFI firmware before allowing the processor to start booting.
Serious question - how well does UEFI secure boot protect against an attacker with a high degree of physical access to the machine? Online docs focus mostly on the software/firmware security but less on the hardware side. Is hardware security specified, or left up to individual vendors?
> how well does UEFI secure boot protect against an attacker with a high degree of physical access to the machine?
Everything is relative.
When enabled, what Secure Boot ensures is that only boot media signed by a trusted a key (which unless user-replaced, typically are the vendor-provided key which trusts MS Windows and common Linux-distros) can be booted.
This guarantees that the base OS and kernel booted by the machine can be trusted to not be tampered with by untrusted parties. That is, the most important part of the OS is protected against malicious modifications and attacks by the firmware.
However if this is the only security-measure you have, there is nothing preventing a physical attacker from extracting the drive into another machine, and on this machine modify non-boot related OS-files to introduce a backdoor or trojan, and then put the drive back into the original machine.
You will then boot a trusted kernel, which later on may load malicious code. Secure boot alone does not protect against a scenario like this.
But if you use Secure Boot together with and BitLocker, LUKS or other full-disk encryption solutions, you should be reasonably secure, even against physical attackers.
Basically Secure Boot is not a full security solution, but it is the base which you need for a fully trusted, tamper-proof computing environment. Without it, you wouldn't know if someone is logging your password or not when unlocking the encrypted drives.
It's being presented as something revolutionary and new, while that's clearly not the case.
And it provides Apple with the means to enforce platform-lock in, not only on its mobile line of offerings, but also on their regular laptops and machine, which traditionally has been 100% open computing owner by the end-users.
Which is why it is being widely criticized as unwanted, as a misfeature.
The article reinforces my disappointment in Apple. First they use an Apple variant of Intel EFI 1.10 forever, even well passed the time UEFI incorporated Secure Boot. Instead of writing up a critique and proposal to fix any problems/limitations with UEFI Secure Boot, Apple has to go do a damned proprietary thing. Again.
Also, the latest Macs do not contain the Microsoft UEFI signing key, only the Microsoft Windows and Applel signing keys. So the only way to boot Linux is to disable Secure Boot, leaving people less secure.
> Does this have any bearing on running linux on macbooks
Unlike on PCs, on T2 Macs Linux will only be bootable with Secure boot disabled making the system much less secure.
To make matters worse, the T2 chip administers access to the built in SSD, so it will be completely inaccessible for Linux to use for anything.
When Apple stops supporting this machine, you won’t be able to keep it chugging by loading another OS.
I could say Apple is trying to terminate the only remaining computing platform which respects end-user freedom and ownership, but I’m not sure if it would be a joke or not...
> the T2 chip administers access to the built in SSD, so it will be completely inaccessible for Linux to use for anything.
This isn’t true. You can install Linux on this, providing you disable Secure Boot. You can’t currently access the SSD, but that’s more the result of a driver not existing than it being inherently disallowed.
> You can’t currently access the SSD, but that’s more the result of a driver not existing than it being inherently disallowed.
That's not clear yet. There is a NVMe driver available in Linux which works fine with pre-T2 Macs. On T2 Macs however the whole platform resets a few seconds after initializing the NVMe controller. The question is: Is that a bug in the driver or NVMe implementation of the T2 chip or something Apple does intentionally?
I can envision a scenario where T2, when booted with Secure Boot disabled, tries to protect a Secure Boot OS and user data stored on the internal mass storage device in the event of the user subsequently re-enabling Secure Boot thus adding a layer of guarantee that everything is safe even during the time window when Secure Boot was disabled.
If intentional, this behaviour is nonetheless not documented in the whitepaper.
In such a scenario, a possible solution could be to offer an option to force an internal disk erasure upon toggling secure boot, in which case the internal device would be cleared for non-secure OS access.
That's interesting; I was not aware of the exact circumstances around why this driver didn't exist. Do you know where I could look to find more detail on the state of development for this?
Even with secure boot disabled you can't install Linux on the internal SSD. Installing Linux on a Mac has already been very flaky for the last few years, but now is impossible.
The likely problem is a lack of driver support for using the T2 as an SSD controller. I don’t think, based on Apple’s white paper, that they did anything to explicitly block Linux from accessing the internal SSD - it just needs to go through the T2 for that.
Hopefully someone is working on the necessary driver support - these laptops are still very new so maybe nobody has gotten around to it yet.
Apple is actively blocking unsigned software from accessing the internal storage as a security measure and providing no means to add allowed keys. Its possible there is a defect in this security that could be exploited but it would be explicitly a bug and would be liable to be patched in the next version of the software. You have completely misread the situation. This is apple taking over your machine while still expecting you to pay for it.
The T2 does so much, essentially running an OS comparable to iOS. The author even suggests it might allow apps.
It doesn't seem like it's a gain in security. Instead of attacking the "main system", you can just attack the T2; it's similar in complexity, meaning it will have similar vulnerabilities.
It's not because of the T2 though - it's because of the Secure Enclave holding the keys for disk encryption and firmware/kernel signatures.
They might have bundled them together, but the layer around the secure part is just another system - it doesn't make anything more secure. All it's functions could have been taken up by the main system.
The only possible security win is by making BridgeOS simpler and less likely to have vulnerabilities.
I'd still say it's a net gain overall†, although the Great Bundling is questionable and definitely concerning in terms of attack surface, yet the synergies when finding and fixing vulnerabilities should not be taken lightly.
† It's overall a good thing evil maid/law enforcement/whatever doesn't get to have trivial access to the user's device anymore.
I think this can't be stated enough. The fact of the matter is that pre T2, evil maid attacks were ridiculously easy. Now they're at least as secure as iOS -- which also means that shared vulnerabilities can be patched and detected. By no means is it perfect security, but it's a heck of a lot better than "stick boot disk in and gain keys to the kingdom."
For so long we've gone by the mantra that physical access means you have root. Now we're a step ahead of that -- which is great for data privacy.