3 ms·

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?

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?