131–140 of 272 posts
Earlier quoted context omitted.
That would be a disaster. Or imagine what would happen if you just disabled secure boot, your computer will be infected with viruses and your bank account emptied instantly I reckon
Secure boot doesn't stop user-space malicious activity. I'd argue that it only helps check a tick box on corporate security manifest, as it indicates the kernel being booted, is not tampered with.
It's totally crazy that we have to go through Microsoft to sign things to be able to have our OS run on third parties computers, and that Microsoft manage to win about this so easily as it was never seriously challenged.
Basically every x64 computer is intended to be able to run Windows. Hence MS had to be involved, and I suppose nobody else with serious money wanted the burden. AFAICT you can still disable Secure Boot in most UEFI firmware, and boot anything you like (or not like, if an attacker tampers with your system).
Honestly I wish they(where they is them that designed this whole broken system) did it it right. On first boot you would set up some keys, now you are your own trust root, and when you you want Microsoft to manage your system, perfectly reasonable, managing systems is scary, you sign their keys and add them to the store. The problem is at a low level it all sort of just works, but nobody want to design that user interface. nobody wants to write the documentation required to explain it to joe random user. Nobody wants to run the call center dealing 24/7 walking people through a complicated process, patiently getting them unstuck when they loose their keys, explaining what a trust root is and why they now have to jump through hoops to set one up.
I like to believe that had they done it right initially, the ui would have been molded into something that just works and the client base would also get molded into expecting these key generations steps. But I am also an optimist, so perhaps not and it is exactly as scary and thankless a task as I described above. But we will never know, Microsoft took the easy way out, said we will hold the keys. And now you are a serf on your own machine. Theoretically there is a method to install your own keys, and it may even work, but the process is awkward(never really being meant for mass use) and you are dependent on the vendor to care enough to enable it. Many don't.
Earlier quoted context omitted.
It makes more sense if you view it for what it is: Honest Satya's Certificate Authority. Microsoft showed they can semi-competently run a PKI. The end. Now had the Linux folks stepped up to the plate early on, instead of childishly acting like Secure Boot was the computing antichrist, the story might be different. But they didn't. We only have shim because some people at Red Hat had the common sense to play ball.
Secure Boot is the computing antichrist, and Linux folk were 100% right to rally against it. As well as a whole bunch of other "Trusted Computing" garbage.
Earlier quoted context omitted.
mind to elaborate? I'd love to know if my machine has been compromised with early boot stage "meta-hypervisor" or not. the promise of secure boot and trusted computing is backdoor-free boot. what is in your eyes evil and garbage about that?
Who controls the fucking certs? "My computer was compromised with an early boot stage hypervisor backdoor" happens basically never. It's an attack vector that exists almost entirely in the minds of infosec fucktards. "My brand new device ships with vendor-selected boot certificates that can't be changed, can't be overridden, and control what software I can install onto my own device" happens with every other smartpho…
Earlier quoted context omitted.
Secure Boot's benefits are definitely not as strong (I don't think flashing custom backdoored firmware is a common attack vector for personal computers), but FDE is still useful in case your laptop gets stolen, because thieves looking for sensitive data on a hard drive is a thing that does actually happen. I also wouldn't really say it's much trouble. If you have a TPM and use systemd, you can set it up to unlock FDE…
SB does not protect against backdoored firmware at all. You would need something like BootGuard which is a separate feature.
My understanding is that at least on Android you can't modify the system: you have to format everything if you want to make a change at this level.
What security benefit did adding an expiry date to the certificate provide? "Oh no! Someone has gotten our secret key and is certifying new shims! ... Not to worry, the certificate will expire in 14 years. Everything is fine!"
Does anyone know the rationale for such expiry?
Earlier quoted context omitted.
There is no basic firmware maintenance to do. Firmware is supposed to be properly engineered, immutable, still to this day sometimes physically wired as 1s and 0s. It doesn't make sense to have expiry dates carved in stone.
Firmware needs maintenance because unless you're doing stuff for the aerospace industry, you're not mathematically proving that your firmware is bug-free. Eventually someone will need to install updates. Well-written firmware doesn't need to be updated for the key database to get updated. However, some vendors messed up and now require firmware updates, while others simply store the new key in NVRAM.
Earlier quoted context omitted.
It makes more sense if you view it for what it is: Honest Satya's Certificate Authority. Microsoft showed they can semi-competently run a PKI. The end. Now had the Linux folks stepped up to the plate early on, instead of childishly acting like Secure Boot was the computing antichrist, the story might be different. But they didn't. We only have shim because some people at Red Hat had the common sense to play ball.
Maybe this isn't a great take, but RedHat/LKF/etc could obviously run a 'semi-competent' PKI, and probably should be. But doing so would allow PC vendors to cleanly segment machines between Windows and Linux (+$$), so perhaps it made the best sense to lay-low and use MS infrastructure for this.
Not out of malice, necessarily, but at least incompetence.
Likewise, having Microsoft signing the shim also means that any Linux installation with the signed shim can install on any system that supports Windows, whereas if RedHat had their own 100% comptent, rock-star PKI then a huge proportion of systems sold today would not be able to run Linux unmodified because the manufacturers wouldn't bother.
Earlier quoted context omitted.
It makes more sense if you view it for what it is: Honest Satya's Certificate Authority. Microsoft showed they can semi-competently run a PKI. The end. Now had the Linux folks stepped up to the plate early on, instead of childishly acting like Secure Boot was the computing antichrist, the story might be different. But they didn't. We only have shim because some people at Red Hat had the common sense to play ball.
orrr we just have official institutions which do this and enforce vendors to add certificates from other trusted parties. not only microsoft is able to do this. also microsoft already also had fallout regarding signing. and secure boot is still the antichrist, but we have to live with them.
A public signing institution (or at least, a not-for-profit one) would be a great idea, but it wouldn't solve the core issue that we're worried about.
Earlier quoted context omitted.
What kinds of attacks was Secure Boot designed to mitigate? Is it the evil maid attack? Or an accidentally ran with `sudo` program can indeed screw your entire boot process and inject rootkits etc.? Or is it something else?
> What kinds of attacks was Secure Boot designed to mitigate? Boot sector viruses, or their modern equivalents. Basically, anything which injects itself into the boot chain before the antivirus can start; after that point, the antivirus is supposed to be able to stop any malware. That is, they wanted to prevent malware from being able to hide from the antivirus by loading before it.
The firmware validates the shim. The shim validates the boot loader. The boot loader validates the kernel. The kernel validates the kernel modules.
Once you have that chain of trust, you can also add in other factors; encrypt your disk using a key, seal the key in the TPM, and lock that key behind validation of the firmware and the boot loader. Your system boots, those different components are measured into the PCRs, and if the combination is correct the key is released and your disk can be decrypted automatically. Now if someone boots your system using a different firmware or boot loader, the TPM won't release the key, and your disk can't be decrypted except by someone with the passphrase, recovery key, etc.
Without secure boot, you can't trust that any of those components aren't reporting falsified measurements to the PCRs, lying to the TPM, and getting access to the key to decyrpt your disk despite booting from a compromised USB drive. That, of course, means you can just encrypt your disk using only a passphrase that you manually enter, but for a lot of users (sadly) that's too complex and they'll choose not to use disk encryption at all.
Case in point, TouchID and FaceID are seen as alternatives to using a PIN or passphrase to unlock your iPhone, but they're actually meant as alternatives to not locking your phone at all - a way to make device security transparent enough that everyone will use it. Without a secure chain of trust from the firmware to the kernel, that's not really an option.