Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Secure Boot in the Era of the T2

duo.com

Post reply on HN
Print view View original

51–60 of 97 posts

Re: Secure Boot in the Era of the T2

#51

Post by yeloboy »

michaelmrose wrote: post #50
nneonneo wrote: post #15

Earlier quoted context omitted.

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 exp…

Not if you disable secure boot. Imo they're probably right about Linux not being able to talk to T2. We'll see about that, I guess.

Re: Secure Boot in the Era of the T2

#52

Post by extrapickles »

xvector wrote: post #13
userbinator wrote: post #6

Earlier quoted context omitted.

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…

> 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 unlo…

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.

Re: Secure Boot in the Era of the T2

#53

Post by solarkraft »

nneonneo wrote: post #30
cmurf wrote: post #19

Earlier quoted context omitted.

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 boo…

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 ah…

> But the "typical scenario" would be a user adding a generic UEFI CA that leaves them open to a modified or malicious OS

What's the downside (to allowing it)? Do they think they need to protect users from themselves?

Re: Secure Boot in the Era of the T2

#54

Post by isostatic »

extrapickles wrote: post #52
xvector wrote: post #13

Earlier quoted context omitted.

> 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 unlo…

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 yo…

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.

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

Re: Secure Boot in the Era of the T2

#55

Post by tremon »

geofft wrote: post #31
userbinator wrote: post #6

Earlier quoted context omitted.

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…

> 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…

The only thing is we've distinguished physical ownership and mere physical possession.

From a legal standpoint, when you buy a John Deere tractor, do you attain physical ownership or is the object merely in your physical possession?

Re: Secure Boot in the Era of the T2

#56

Post by lloeki »

josteink wrote: post #20
Shank wrote: post #3

> 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…

> 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 spe…

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

[0] https://wiki.archlinux.org/index.php/Secure_Boot

[1] http://www.rodsbooks.com/efi-bootloaders/secureboot.html#fin...

Re: Secure Boot in the Era of the T2

#57

Post by lloeki »

Dunedan wrote: post #32
saagarjha wrote: post #28

Earlier quoted context omitted.

> 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…

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.

Re: Secure Boot in the Era of the T2

#58

Post by lloeki »

akvadrako wrote: post #12
IMcD23 wrote: post #9

Earlier quoted context omitted.

Try pulling data off my iPhone with physical access. Now, try pulling data off a pre-T2 Mac. The T2 brings many security improvements to the Mac.

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…

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.

Re: Secure Boot in the Era of the T2

#59

Post by bengale »

michaelmrose wrote: post #47
geofft wrote: post #31

Earlier quoted context omitted.

> 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…

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…

This is a driver issue.

Re: Secure Boot in the Era of the T2

#60

Post by dingaling »

X-Istence wrote: post #48
josteink wrote: post #43

Earlier quoted context omitted.

> 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-…

> 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 yo…

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

Post reply on HN