6 ms·

Can Linux just ignore the entire cancer that secure boot represents? There is literally no upside for the user.

by dingo_bat 9y ago

benbristow 9y ago
Other than ensuring that you're booting what you think you're actually booting
- dingo_bat 9y ago
  I don't know if this is a general problem, but I have never had this issue. My system always boots whatever I installed.
  - Jasper_ 9y ago
    How are you sure you don't have a so-called "boot kit" on your machine?
    - dingo_bat 9y ago
      Because there are only 2 ways of that happening: 1. I run a malware as root which modifies my image. I don't run anything as root except apt. So this is impossible. 2. Someone steals my computer and modifies the disk. Again, if they have physical access, I have already failed in my security. So this scenario is irrelevant. Am I missing anything?
      - mjg59 9y ago
        You run malware as a user that's able to subvert some other component of your distribution (such as beep on Debian) to gain root and it does that?
        dingo_bat 9y ago
        Gaining root without credentials is a bug of the highest order and must be fixed immediately. Existence of rare exploits that do allow privilege escalation does not mean we take capabilities away from root.
        mjg59 9y ago
        It actually does - why do you think /dev/mem is more restricted than it was in 1993?
        viraptor 9y ago
        Seccomp, selinux, grsec, namespaces, blocking module loading and many others absolutely exist to take capabilities away (or can be used that way) from full user access (root or other) to limit what an unknown-at-the-moment exploit can do.
        deleted 9y ago
        [deleted]
      - Jasper_ 9y ago
        1. local-root exploits exist and are quite common. It is possible for an unknown kernel bug to get root access. Remote code execution exploits are also common in browsers and also just all across the Linux desktop in general. 2. apt packages can run arbitrary bash scripts as root as part of their install and update process. Hopefully your third-party apt repo hygiene is good. 3. Just because you only explicitly run apt as root, does not mean no program runs as root. setuid executables exist and are unfortunately quite common in Debian.
        dingo_bat 9y ago
        > local-root exploits exist and are quite common. It is possible for an unknown kernel bug to get root access. Remote code execution exploits are also common in browsers and also just all across the Linux desktop in general. I highly doubt it. Privilege escalation exploits are rare and fixed with utmost priority. > apt packages can run arbitrary bash scripts as root as part of their install and update process. Hopefully your third-party apt repo hygiene is good. Yeah, a root user should be responsible. > Just because you only explicitly run apt as root, does not mean no program runs as root. setuid executables exist and are unfortunately quite common in Debian. And I assume that when the root user installed those apps, he was careful and selective and did not include malware.
        tedunangst 9y ago
        > Privilege escalation exploits are rare and fixed with utmost priority. A statement which would be much improved with numbers. How rare? Fixed how quickly?
      - cjbprime 9y ago
        You're missing the entire field of remote exploits. Meltdown, for example, could be exploited by JavaScript code running as non-root. It's not about what you explicitly choose to run as root at the command line. That's a tiny fraction of the code that executes as root on your machine. It's about what software can do to somehow gain access to root's privilege level via exploits.
        dingo_bat 9y ago
        > You're missing the entire field of remote exploits. Meltdown, for example, could be exploited by JavaScript code running as non-root. Yeah and that was a really big deal. Fixes were pushed in record time. > It's about what software can do to somehow gain access to root's privilege level via exploits. The correct way to deal with that is to plug exploits or write code that is less likely to be exploited. Taking away privileges from root is the exact opposite of what we should be doing. Root access should be protected, and any bugs that break this barrier without the user's credentials should be fixed/prevented. The root user should have absolute power to do anything. This is the basic ethos of Linux. Taking away power from the user results in ios. I don't want Linux distros/systems to start behaving like ios.
        ksk 9y ago
        >Root access should be protected, and any bugs that break this barrier without the user's credentials should be fixed/prevented. >The root user should have absolute power to do anything. This is the basic ethos of Linux. They're just splitting 'root' into two parts. No power has been taken away.
      - emilyst 9y ago
        > 1. I run a malware as root which modifies my image. I don't run anything as root except apt. So this is impossible. 1. What if apt is compromised? 2. What if apt installs something which is compromised? 3. What if you run something which is compromised and escalates privilege?
        dingo_bat 9y ago
        > 1. What if apt is compromised? Then fix it. > 2. What if apt installs something which is compromised? This implies apt is compromised. Goto above. > 3. What if you run something which is compromised and escalates privilege? If something is able to escalate privilege that's a kernel bug of the highest order and must be fixed asap.
        iknowstuff 9y ago
        I'm guessing defense in depth is a foreign concept to you?
- tremon 9y ago
  There are other ways to do that, e.g. by encrypting the disk and booting from usb key or sftp/https network sources.
  - josteink 9y ago
    But you don’t know if the OS you’re trying to boot and enter passwords into to decrypt has been tampered or not. Not without Secure Boot. Really... why would I as user not want it?
    - gmueckl 9y ago
      Because almost no vendor wants to give you the keys to your system voluntarily. If secure boot puts the users in charge, I'm all for it. But there are forces at work to subvert the system to achieve a better vendor lock-in. And providing them with better means to that end is unethical.
      - freeone3000 9y ago
        I've never been on a system where I couldn't swap the keys in UEFI. Does mokutil not work on your system?
        gmueckl 9y ago
        You know that this feature only works because Microsoft added it to the requirements of the Windows Logo program for x86 based computers almost at the last minute. Mainboard manufacturers would otherwise cut corners and add the MS signing key as the only unchangeable key to the system. At the same time, MS specified for ARM computers that want to run Windows that the key must be fixed and irreplaceable.
      - tedunangst 9y ago
        Go into the BIOS and set your own keys.
        9y ago
Arbalest 9y ago
Secure Boot is cool when you control the keys. That's quite a lot of work though. Given how easy it is to bypass for consumer systems, yes the defaults suck. However, it makes a lot more sense in enterprise, where someone might actually be employed to manage the chain of trust.
itakedrugs 9y ago
I wish that we would at least have the option to buy a new computer without it.
- paulmd 9y ago
  You can't just go out and buy one, but there are millions of AMD Ryzen chips with a known flaw in their BIOS and PSP signature-validation routines just ripe for a PSP-Cleaner type application. Go forth and be fruitful. https://community.amd.com/community/amd-corporate/blog/2018/03/21/initial-amd-technical-assessment-of-cts-labs-research https://community.amd.com/community/amd-corporate/blog/2018/... https://blog.trailofbits.com/2018/03/15/amd-flaws-technical-summary/ https://blog.trailofbits.com/2018/03/15/amd-flaws-technical-...

Can Linux just ignore the entire cancer that secure boot represents? There is literally no upside for the user.

benbristow 9y ago

Other than ensuring that you're booting what you think you're actually booting

dingo_bat 9y ago
I don't know if this is a general problem, but I have never had this issue. My system always boots whatever I installed.
- Jasper_ 9y ago
  How are you sure you don't have a so-called "boot kit" on your machine?
  - dingo_bat 9y ago
    Because there are only 2 ways of that happening: 1. I run a malware as root which modifies my image. I don't run anything as root except apt. So this is impossible. 2. Someone steals my computer and modifies the disk. Again, if they have physical access, I have already failed in my security. So this scenario is irrelevant. Am I missing anything?
    - mjg59 9y ago
      You run malware as a user that's able to subvert some other component of your distribution (such as beep on Debian) to gain root and it does that?
      - dingo_bat 9y ago
        Gaining root without credentials is a bug of the highest order and must be fixed immediately. Existence of rare exploits that do allow privilege escalation does not mean we take capabilities away from root.
        mjg59 9y ago
        It actually does - why do you think /dev/mem is more restricted than it was in 1993?
        viraptor 9y ago
        Seccomp, selinux, grsec, namespaces, blocking module loading and many others absolutely exist to take capabilities away (or can be used that way) from full user access (root or other) to limit what an unknown-at-the-moment exploit can do.
      - deleted 9y ago
        [deleted]
    - Jasper_ 9y ago
      1. local-root exploits exist and are quite common. It is possible for an unknown kernel bug to get root access. Remote code execution exploits are also common in browsers and also just all across the Linux desktop in general. 2. apt packages can run arbitrary bash scripts as root as part of their install and update process. Hopefully your third-party apt repo hygiene is good. 3. Just because you only explicitly run apt as root, does not mean no program runs as root. setuid executables exist and are unfortunately quite common in Debian.
      - dingo_bat 9y ago
        > local-root exploits exist and are quite common. It is possible for an unknown kernel bug to get root access. Remote code execution exploits are also common in browsers and also just all across the Linux desktop in general. I highly doubt it. Privilege escalation exploits are rare and fixed with utmost priority. > apt packages can run arbitrary bash scripts as root as part of their install and update process. Hopefully your third-party apt repo hygiene is good. Yeah, a root user should be responsible. > Just because you only explicitly run apt as root, does not mean no program runs as root. setuid executables exist and are unfortunately quite common in Debian. And I assume that when the root user installed those apps, he was careful and selective and did not include malware.
        tedunangst 9y ago
        > Privilege escalation exploits are rare and fixed with utmost priority. A statement which would be much improved with numbers. How rare? Fixed how quickly?
    - cjbprime 9y ago
      You're missing the entire field of remote exploits. Meltdown, for example, could be exploited by JavaScript code running as non-root. It's not about what you explicitly choose to run as root at the command line. That's a tiny fraction of the code that executes as root on your machine. It's about what software can do to somehow gain access to root's privilege level via exploits.
      - dingo_bat 9y ago
        > You're missing the entire field of remote exploits. Meltdown, for example, could be exploited by JavaScript code running as non-root. Yeah and that was a really big deal. Fixes were pushed in record time. > It's about what software can do to somehow gain access to root's privilege level via exploits. The correct way to deal with that is to plug exploits or write code that is less likely to be exploited. Taking away privileges from root is the exact opposite of what we should be doing. Root access should be protected, and any bugs that break this barrier without the user's credentials should be fixed/prevented. The root user should have absolute power to do anything. This is the basic ethos of Linux. Taking away power from the user results in ios. I don't want Linux distros/systems to start behaving like ios.
        ksk 9y ago
        >Root access should be protected, and any bugs that break this barrier without the user's credentials should be fixed/prevented. >The root user should have absolute power to do anything. This is the basic ethos of Linux. They're just splitting 'root' into two parts. No power has been taken away.
    - emilyst 9y ago
      > 1. I run a malware as root which modifies my image. I don't run anything as root except apt. So this is impossible. 1. What if apt is compromised? 2. What if apt installs something which is compromised? 3. What if you run something which is compromised and escalates privilege?
      - dingo_bat 9y ago
        > 1. What if apt is compromised? Then fix it. > 2. What if apt installs something which is compromised? This implies apt is compromised. Goto above. > 3. What if you run something which is compromised and escalates privilege? If something is able to escalate privilege that's a kernel bug of the highest order and must be fixed asap.
        iknowstuff 9y ago
        I'm guessing defense in depth is a foreign concept to you?
tremon 9y ago
There are other ways to do that, e.g. by encrypting the disk and booting from usb key or sftp/https network sources.
- josteink 9y ago
  But you don’t know if the OS you’re trying to boot and enter passwords into to decrypt has been tampered or not. Not without Secure Boot. Really... why would I as user not want it?
  - gmueckl 9y ago
    Because almost no vendor wants to give you the keys to your system voluntarily. If secure boot puts the users in charge, I'm all for it. But there are forces at work to subvert the system to achieve a better vendor lock-in. And providing them with better means to that end is unethical.
    - freeone3000 9y ago
      I've never been on a system where I couldn't swap the keys in UEFI. Does mokutil not work on your system?
      - gmueckl 9y ago
        You know that this feature only works because Microsoft added it to the requirements of the Windows Logo program for x86 based computers almost at the last minute. Mainboard manufacturers would otherwise cut corners and add the MS signing key as the only unchangeable key to the system. At the same time, MS specified for ARM computers that want to run Windows that the key must be fixed and irreplaceable.
    - tedunangst 9y ago
      Go into the BIOS and set your own keys.
      - 9y ago

Arbalest 9y ago

Secure Boot is cool when you control the keys. That's quite a lot of work though. Given how easy it is to bypass for consumer systems, yes the defaults suck. However, it makes a lot more sense in enterprise, where someone might actually be employed to manage the chain of trust.

itakedrugs 9y ago

I wish that we would at least have the option to buy a new computer without it.

paulmd 9y ago
You can't just go out and buy one, but there are millions of AMD Ryzen chips with a known flaw in their BIOS and PSP signature-validation routines just ripe for a PSP-Cleaner type application. Go forth and be fruitful. https://community.amd.com/community/amd-corporate/blog/2018/03/21/initial-amd-technical-assessment-of-cts-labs-research https://community.amd.com/community/amd-corporate/blog/2018/... https://blog.trailofbits.com/2018/03/15/amd-flaws-technical-summary/ https://blog.trailofbits.com/2018/03/15/amd-flaws-technical-...