Live data from Hacker News

Brave New Trusted Boot World

0pointer.net

141–150 of 178 posts

Re: Brave New Trusted Boot World

#141

I fail to see what all the panic is about. All of the SystemD tools mentioned here (iirc) don't actually rely much on SystemD proper and especially systemd-boot and the boot stub are just SystemD in name (I use both). But regardless, this entire article is about how to have an actually secure boot on Linux (and not remote attestation), something which is certainly good for the user. Otherwise you're actually more eas…

> I personally use a boot-stub based booting method with my own SB keys

Same here - stub, kernel, initrd and embedded cmdline all in a signed UKI on the ESP. I do encrypt my root however, so I wouldn't go as far as "painless" for the grub->efibootmgr switch (but I also switched initramfs generator so... always keep a rescue stick around).

But it's all about ownership and trust. I control the keys - hence I am the owner of my computer - and I don't trust e.g. Microsoft[1] to not eventually try to fuck me over. But that's not the important part.

> Also, I don't understand where remote attestation entered the conversation here, and I also don't see why that can't be a community based thing (al la let's encrypt is now everyone's CA) where you can choose your providers or even roll it yourself.

Remote attestation is mentioned five times in TFA and is where this can get really pernicious - indirectly limiting user choice because $safety_critical_industry (e.g. banking) only allows "the corporate keys" (likely including a few Linuxes too, but something like Gentoo couldn't be). They'll even have very good and completely valid security reasons for not allowing arbitrary user keys, but they'd lock me down to approved choices remotely. A reverse AGPL if you will.

Of course, workarounds will exist: "just multiboot", "just use multiple devices", "just choose the bank that allows you to whitelist your key" (assuming there is one, it's nice to dream) - but user freedom is reduced without malicious intent being strictly necessary anywhere in the process.

That's focusing on the negatives with my paranoiac hat on, of course.

[1] https://www.theregister.com/2022/07/07/lennart_poettering_re...

Re: Brave New Trusted Boot World

#142

Earlier quoted context omitted.

> There is really no need to transform purely technical arguments into personal attacks. This just discourages participating into free software development. While I agree with you in general, for some reason this particular developer tends to take decisions that have very extensive consequences and make choice extremely difficult.

A developer that has been able to make tough choices and drive them well enough to get mass adoption? He definitely isn't perfect but this sounds like quite the feat in Open Source.

> A developer that has been able to make arbitrary choices and drive them thorough his employers connections to get mass adoption

FTFY

Re: Brave New Trusted Boot World

#143

Earlier quoted context omitted.

I don't want my users to be clueless. I want them to better understand the technical systems they use every day so they can employ them more effectively. But they and I have a job as well. When I was in tech support, I spent hours some weeks with one particular user working on her software and teaching her more effective use of her computer. But I could only do that during slow weeks: I didn't have enough time to do…

Sounds like you're a good sysadmin and mentor. There's no possible way you should have to take on the burden of schooling everyone. You probably already go far beyond the call of duty. What we need to do with Digital Self Defence is raise awareness of civic cyber-security needs from school ages 5 upwards (My government in the UK have started on this project). We also need to screen for digital literacy.

I admire your positive view on people but I feel like you vastly overestimates both the ability to learn and the willingness to care of a huge chunk of the population. If we talk about corporate environments with hundreds of thousands of employees, you will absolutely always have malicious or drunk or just plain uncaring people that will not care at all what happens when they click that one blinking link in that one special email from the long lost relative.

The goal to teach people how technology works is admirable and necessary, but it is no defence against a motivated attacker. The attackers will always have a massive information advantage just because they have so much more time to aquire it.

Re: Brave New Trusted Boot World

#144
post #95
post #2

>System ready for easy remote attestation, to prove validity of booted OS, configuration and local identity >“Democratize” use of PCR policies by defining PCR register meanings, and making binding to them robust against updates, so that external projects can safely and securely bind their own data to them (or use them for remote attestation) without risking breakage whenever the OS is updated. In what world is this a…

This is where computing as a whole is headed because it's the ONLY way to provide defense in depth against cyberattacks. Signed code path from first boot to user space code. Remote attestation because you can NEVER trust the client. Microsoft and especially Apple are already doing this. Linux needs an answer, and "no, it's too user hostile" is NOT a valid answer; it will just make Linux an untenable security risk. It…

Lack of electricity is a cyberattack too.

Re: Brave New Trusted Boot World

#145

I fail to see what all the panic is about. All of the SystemD tools mentioned here (iirc) don't actually rely much on SystemD proper and especially systemd-boot and the boot stub are just SystemD in name (I use both). But regardless, this entire article is about how to have an actually secure boot on Linux (and not remote attestation), something which is certainly good for the user. Otherwise you're actually more eas…

> but ironically, don't encrypt my root, so go figure Oh man that takes me back. The last time I went down that rabbit hole was ~2015, I tried to implement a "fully encrypted" setup and started with Ubuntu (I know I know). Something something LUKS. I spent ~2 days tinkering with it and never got it to work, something with the setup flow was totally broken if you also tried to encrypt root (or boot? idk like I said it…

> the windows partition was using hardware-bitlocker

That sounds way too exciting, even without that involved I keep my Windows install on its own disk.

Re: Brave New Trusted Boot World

#146

I fail to see what all the panic is about. All of the SystemD tools mentioned here (iirc) don't actually rely much on SystemD proper and especially systemd-boot and the boot stub are just SystemD in name (I use both). But regardless, this entire article is about how to have an actually secure boot on Linux (and not remote attestation), something which is certainly good for the user. Otherwise you're actually more eas…

> but ironically, don't encrypt my root, so go figure Oh man that takes me back. The last time I went down that rabbit hole was ~2015, I tried to implement a "fully encrypted" setup and started with Ubuntu (I know I know). Something something LUKS. I spent ~2 days tinkering with it and never got it to work, something with the setup flow was totally broken if you also tried to encrypt root (or boot? idk like I said it…

[deleted]

Re: Brave New Trusted Boot World

#147
post #145

Earlier quoted context omitted.

> but ironically, don't encrypt my root, so go figure Oh man that takes me back. The last time I went down that rabbit hole was ~2015, I tried to implement a "fully encrypted" setup and started with Ubuntu (I know I know). Something something LUKS. I spent ~2 days tinkering with it and never got it to work, something with the setup flow was totally broken if you also tried to encrypt root (or boot? idk like I said it…

> the windows partition was using hardware-bitlocker That sounds way too exciting, even without that involved I keep my Windows install on its own disk.

I mean I love the idea right? Software FDE comes with a performance hit, as well as increased wear on the SSD.

With hardware FDE the data written to the raw flash is always encrypted, the AES key is just 0 by default. Macs work this way AFAIK. With "hardware bitlocker" you just change that key (on a fresh drive).

Full performance, better security. Seems awesome huh? Well being outside the happy-path when it comes to hardware configs on free software is just asking for trouble...

Re: Brave New Trusted Boot World

#148
Smh, the FUD is suffocating in here. And really, a round of applause for everyone butting into say they don't need this. Do you have a habit of doing this for all features?

Sorry, but I expect my Linux install to be at least as secure as my Windows (Pro) installation. And without this, it's not. It's that simple. In years, most of you will be benefiting from this, it will become table stakes and the FUD will subside.

It's hard to really read this thread. If you care about user freedom, this sure ain't got nothing to do with it. Other than giving me the freedom to have a more secure computer.

Just sad to see the FUD cause people to just get so activated without even understanding the stakes at hand. (Think. It's not like MS is watching this feature to decide whether or not to allow user-key-enrollment on the ARM Surface).

Re: Brave New Trusted Boot World

#149

I fail to see what all the panic is about. All of the SystemD tools mentioned here (iirc) don't actually rely much on SystemD proper and especially systemd-boot and the boot stub are just SystemD in name (I use both). But regardless, this entire article is about how to have an actually secure boot on Linux (and not remote attestation), something which is certainly good for the user. Otherwise you're actually more eas…

which is admittedly a flaw so long as we cannot audit them

provided ... MS hasn't f'd that up

I think you pinpointed the two reasons people are fuming about this.

Re: Brave New Trusted Boot World

#150

Smh, the FUD is suffocating in here. And really, a round of applause for everyone butting into say they don't need this. Do you have a habit of doing this for all features? Sorry, but I expect my Linux install to be at least as secure as my Windows (Pro) installation. And without this, it's not. It's that simple. In years, most of you will be benefiting from this, it will become table stakes and the FUD will subside.…

I just don’t trust a company and its employees which actively tried to kill Linux back in the day.

Adding the fact that said company is designer, enforcer and gatekeeper of such technology makes everything more worrisome.

Lastly, telling that people are spreading FUD against the company which defined and is synonymous with FUD is ironic.

That’s all,

Thank you.

Post reply on HN