4 ms·

> If an "act of aggression" would happen, I would have no recourse against it. You have the same recourse as you've always had. Vote with your wallet, don't bu

> If an "act of aggression" would happen, I would have no recourse against it. You have the same recourse as you've always had. Vote with your wallet, don't buy the hardware. I am much more concerned about Intel ME and AMD PSP, where's the outrage about that? > But that is besides the fact that these acts of aggression for locking down system did indeed happen numerous times in the industry. Can you please link me some articles/references? This is relevant to my interests, I would like to actually see something that backs up the counter-argument. > On the contrary, you are spreading FUD if you argue for such mechanisms that allegedly are required to protect activists and journalists. That they they would be the primary beneficiaries. This is quite analog to the war on terror justifying security policies. I'm aware I'm stretching things, but the stance "Secure Boot = attack on computing freedom" is quite regularly stretched to argue against many other hardware security features, such as TPM or Secure Enclave. If my laptop is stolen, confidentiality of all my data is only as good as my passphrase. Am I paranoid enough to employ a complex, unique, zxcvbn-proof passphrase? Hell no. I would much rather use four random dictionary words, and let the TPM throttle cracking attempts. (Yes, I know LUKS offers KDF, with a number of iterations picked to reasonably throttle cracking attempts on today's hardware. I would still rather see the cracking stopped dead after 10 attempts, and this physically requires dedicated hardware.) It's 2023, Thinkpads have been shipping with TPMs for over a decade, and I still can't easily utilise a TPM to keep the FDE decryption key - is it because the TPM genuinely does not offer tangible improvement over plain LUKS, or is it because it was being actively pushed back against in the free software community, and nobody bothered to integrate the functionality? Repeat this for GPG/SSH/FIDO keys, I am expected to buy a dongle that I can lose, and plug it into a USB port - but can't sensibly utilise the hardware that has been soldered onto my motherboard, which was designed with that explicit purpose? Please correct me if I'm wrong, but all I'm seeing is a pattern of: "dedicated security hardware = attack on freedom", with pushbacks at any attempts to utilise such hardware for the benefit of the user. > The primary vector of malware isn't near boot, it is quite exotic these days. APTs / evil maid never stopped being a thing. Security isn't about what's unlikely, it's about the entire chain. Maybe your targeted attack requires a key logger to remain dormant/undetected until a particular moment in time, six months from now, and the best way to hide it is by paravirtualising your kernel. We've seen attacks way more sophisticated than that (stuxnet). > But that is also irrelevant if I could just spoof any attestation. I agree 100%, attestation is just layers of bullshit. But I still want my device to ring an alarm if an APT is suspected.

PinkSheep 4y ago
> Can you please link me some articles/references? Well explained here: https://gabrielsieben.tech/2022/07/29/remote-assertion-is-coming-back-how-much-freedom-will-it-take/ https://gabrielsieben.tech/2022/07/29/remote-assertion-is-co... So the issue is not the SecureBoot itself, but the ways it can and has been and will be leveraged against the user. If a desktop computer example is not enough, look at how Android phones have increasingly tightened down everything. You can't just take any model and install a custom OS (aka ROM in Android community). It was universally easy 10 years ago, that's why Cyanogenmod became so popular. Now your choices are very limited. > > But that is besides the fact that these acts of aggression A great thread and arguments provided here, how Microsoft (who love open source, according to own PR) will not sign anything GPLv3 for SecureBoot: https://github.com/pbatard/uefi-ntfs/issues/20#issuecomment-739441450 https://github.com/pbatard/uefi-ntfs/issues/20#issuecomment-... Microsoft has the defacto monopoly over the signature process, because nobody embeds any CAs in UEFI except for Microsoft's. What would be a user-friendly way? To preload UEFI with major Linux distros' keys, disabled by default, with an easy first-time setup menu to select what to do. My laptop came with SecureBoot enabled by default although being "OS: FreeDOS" on paper. I had to figure out to disable it to boot into a live distro else it fell into an EFI shell. > Vote with your wallet, don't buy the hardware. > ... I am much more concerned about Intel ME and AMD PSP, where's the outrage about that? With this I just want to say the wallet argument doesn't work when something slowly becomes the status quo and it takes experts/activists to fight back (a minority by numbers). > I still can't easily utilise a TPM [...] and nobody bothered to integrate the functionality? I agree, I'd have liked to enforce SecureBoot post-installation but it is too much hassle for me, I think only RedHat made good improvements in this area where it's actually easily usable (auto signing the kernel image etc.) > Security isn't about what's unlikely, it's about the entire chain. ... But if I followed through, then still the weakest point is/becomes the keyboard. It would be trivial for an evil maid to add a keylogging device between your desktop and the physical keyboard. Do you check the rear IO on each boot? The considerations differ for laptops where you can't just plug something inbetween and need to disassemble it (time required: over night or airport luggage).
- rollcat 4y ago
  Thanks for more insight into this issue. > If a desktop computer example is not enough, look at how Android phones have increasingly tightened down everything. You can't just take any model and install a custom OS (aka ROM in Android community). It was universally easy 10 years ago, that's why Cyanogenmod became so popular. Now your choices are very limited. This is exactly the area where I would double down on the "vote with your wallet" argument. There is enough variety and choice in the Android ecosystem, and if you do really care about running LineageOS / GrapheneOS / PostmarketOS / etc, you probably already know what your options are. > With this I just want to say the wallet argument doesn't work when something slowly becomes the status quo and it takes experts/activists to fight back (a minority by numbers). You will always be able to buy hardware and support vendors that are explicitly non-hostile. System76, Frame.work, MNT... More maintstream options also exist, Dell was shipping laptops with Ubuntu as far as in 2006 (I remember it was big news at the time, I don't know how is it like nowadays). Even Apple seems committed to allowing (quietly encouraging?) third-party OS's, so I'm watching the progress on Asahi as well. > A great thread and arguments provided here, how Microsoft [...] will not sign anything GPLv3 for SecureBoot Complex licenses result in complex issues. I understand why FSF chose to design that license the way they did, but it's my personal opinion that they've caused more harm to the users of their software with it than they've done good. Software has value when it can be used. If I can't use it (e.g. because my vendor won't ship it), it has no value to me. I don't understand why Free Software advocates want their users on non-free platforms to suffer. Just a couple days ago someone on HN suggested that GIMP shouldn't have been ported to M1 Macs[0]. Emacs disables already-working features, because support exists only on macOS[1]. The BSDs had to ship with years, almost decades old forks of GCC[2]. I think these moves are an underhanded attack on the users' four software freedoms. I might have no choice of operating system (e.g. because this is what my employer mandates, this is the hardware that I was able to afford, there is other non-free software I must run to earn my living, etc), and FSF/RMS think I should be punished for that. From my (user's) point of view, neither FSF nor MS care at all about what benefits me - the user, and instead just want to play out some petty political conflict. [0]: https://news.ycombinator.com/item?id=34392834 https://news.ycombinator.com/item?id=34392834 [1]: http://xahlee.info/emacs/misc/emacs_macos_emoji.html http://xahlee.info/emacs/misc/emacs_macos_emoji.html [2]: https://man.openbsd.org/gcc-local.1 https://man.openbsd.org/gcc-local.1 > But if I followed through, then still the weakest point is/becomes the keyboard. Nope, keyboard has no more importance than any other part of the device. Once an adversary has physical access, all bets are off. Nuke it from the orbit, restore from backups, and rotate all credentials.

PinkSheep 4y ago

> Can you please link me some articles/references? Well explained here: https://gabrielsieben.tech/2022/07/29/remote-assertion-is-coming-back-how-much-freedom-will-it-take/ https://gabrielsieben.tech/2022/07/29/remote-assertion-is-co... So the issue is not the SecureBoot itself, but the ways it can and has been and will be leveraged against the user. If a desktop computer example is not enough, look at how Android phones have increasingly tightened down everything. You can't just take any model and install a custom OS (aka ROM in Android community). It was universally easy 10 years ago, that's why Cyanogenmod became so popular. Now your choices are very limited. > > But that is besides the fact that these acts of aggression A great thread and arguments provided here, how Microsoft (who love open source, according to own PR) will not sign anything GPLv3 for SecureBoot: https://github.com/pbatard/uefi-ntfs/issues/20#issuecomment-739441450 https://github.com/pbatard/uefi-ntfs/issues/20#issuecomment-... Microsoft has the defacto monopoly over the signature process, because nobody embeds any CAs in UEFI except for Microsoft's. What would be a user-friendly way? To preload UEFI with major Linux distros' keys, disabled by default, with an easy first-time setup menu to select what to do. My laptop came with SecureBoot enabled by default although being "OS: FreeDOS" on paper. I had to figure out to disable it to boot into a live distro else it fell into an EFI shell. > Vote with your wallet, don't buy the hardware. > ... I am much more concerned about Intel ME and AMD PSP, where's the outrage about that? With this I just want to say the wallet argument doesn't work when something slowly becomes the status quo and it takes experts/activists to fight back (a minority by numbers). > I still can't easily utilise a TPM [...] and nobody bothered to integrate the functionality? I agree, I'd have liked to enforce SecureBoot post-installation but it is too much hassle for me, I think only RedHat made good improvements in this area where it's actually easily usable (auto signing the kernel image etc.) > Security isn't about what's unlikely, it's about the entire chain. ... But if I followed through, then still the weakest point is/becomes the keyboard. It would be trivial for an evil maid to add a keylogging device between your desktop and the physical keyboard. Do you check the rear IO on each boot? The considerations differ for laptops where you can't just plug something inbetween and need to disassemble it (time required: over night or airport luggage).

rollcat 4y ago
Thanks for more insight into this issue. > If a desktop computer example is not enough, look at how Android phones have increasingly tightened down everything. You can't just take any model and install a custom OS (aka ROM in Android community). It was universally easy 10 years ago, that's why Cyanogenmod became so popular. Now your choices are very limited. This is exactly the area where I would double down on the "vote with your wallet" argument. There is enough variety and choice in the Android ecosystem, and if you do really care about running LineageOS / GrapheneOS / PostmarketOS / etc, you probably already know what your options are. > With this I just want to say the wallet argument doesn't work when something slowly becomes the status quo and it takes experts/activists to fight back (a minority by numbers). You will always be able to buy hardware and support vendors that are explicitly non-hostile. System76, Frame.work, MNT... More maintstream options also exist, Dell was shipping laptops with Ubuntu as far as in 2006 (I remember it was big news at the time, I don't know how is it like nowadays). Even Apple seems committed to allowing (quietly encouraging?) third-party OS's, so I'm watching the progress on Asahi as well. > A great thread and arguments provided here, how Microsoft [...] will not sign anything GPLv3 for SecureBoot Complex licenses result in complex issues. I understand why FSF chose to design that license the way they did, but it's my personal opinion that they've caused more harm to the users of their software with it than they've done good. Software has value when it can be used. If I can't use it (e.g. because my vendor won't ship it), it has no value to me. I don't understand why Free Software advocates want their users on non-free platforms to suffer. Just a couple days ago someone on HN suggested that GIMP shouldn't have been ported to M1 Macs[0]. Emacs disables already-working features, because support exists only on macOS[1]. The BSDs had to ship with years, almost decades old forks of GCC[2]. I think these moves are an underhanded attack on the users' four software freedoms. I might have no choice of operating system (e.g. because this is what my employer mandates, this is the hardware that I was able to afford, there is other non-free software I must run to earn my living, etc), and FSF/RMS think I should be punished for that. From my (user's) point of view, neither FSF nor MS care at all about what benefits me - the user, and instead just want to play out some petty political conflict. [0]: https://news.ycombinator.com/item?id=34392834 https://news.ycombinator.com/item?id=34392834 [1]: http://xahlee.info/emacs/misc/emacs_macos_emoji.html http://xahlee.info/emacs/misc/emacs_macos_emoji.html [2]: https://man.openbsd.org/gcc-local.1 https://man.openbsd.org/gcc-local.1 > But if I followed through, then still the weakest point is/becomes the keyboard. Nope, keyboard has no more importance than any other part of the device. Once an adversary has physical access, all bets are off. Nuke it from the orbit, restore from backups, and rotate all credentials.