3 ms·

I don't understand the issue at stake here. > "if you were root you could just replace the on-disk kernel with a backdoored one and reboot." Isn't this a vita

by mcv 6y ago

I don't understand the issue at stake here. > "if you were root you could just replace the on-disk kernel with a backdoored one and reboot." Isn't this a vital necessity? You want to be able to update the kernel to a new version, don't you? Preventing root from being able to do vital system maintenance sounds to me like the opposite of what you want. If an attacker has become root, the system is compromised. As far as I know, security should focus on preventing an intruder from getting root access. Once the intruder gets root access, isn't it kinda pointless to worry about the kernel?

bombcar 6y ago
Replace kernel with unsigned kernel where appropriate. They’re saying basically root should NOT be able to get to an unsigned kernel via swap/hibernation tricks. Who holds the keys is left up for discussion.
- mcv 6y ago
  And I disagree with that. You've got to be able to run your own OS on your own system, don't you? If you disagree with some choices made in the "official" kernel, you should be able to make your own changes. If you work on kernel development, you should be able to test your changes. If root can't control these things, then who can? Besides, even if root can't change the kernel, the system will still be compromised if an intruder gets root access.
  - ravi-delia 6y ago
    You can pretty easily sign your own kernel, it's not just manufacturer discretion.
    - bombcar 6y ago
      Yeah, it's the same as SELINUX - layers of security. I could easily see reasons to have a box that can boot a signed kernel but the signing keys are held by me offline.
  - mindslight 6y ago
    The point is that if the owner has chosen to required signature verification to boot, one shouldn't be able to get around this by restoring from a hibernation image. Imagine you as the party who booted the original kernel, and an evil maid as the party injecting the fake hibernation image. The real problem with TPM and its ilk is that keys owned by the manufacturer are baked in, rather than being owner-changeable by some suitable procedure. Overall, local cryptographic integrity does make sense. Remote Attestation is the actual threat to Freedom, but that's a separate discussion.
mjg59 6y ago
There's three things we really want here: 1) Prevent people gaining inappropriate privileges 2) Detect if people have gained inappropriate privileges 3) Prevent those inappropriate privileges form being persisted If we can achieve (1) then (2) and (3) are irrelevant. If we can't, then (2) depends on the kernel being trustworthy (things like IMA and audit can give strong indications of compromise, but if the attacker can get into the kernel then they can just hide themselves), and (3) is much easier for an attacker to undetectably pull off if they can switch out the on-disk kernel.

by mcv 6y ago

bombcar 6y ago

Replace kernel with unsigned kernel where appropriate. They’re saying basically root should NOT be able to get to an unsigned kernel via swap/hibernation tricks. Who holds the keys is left up for discussion.

mcv 6y ago
And I disagree with that. You've got to be able to run your own OS on your own system, don't you? If you disagree with some choices made in the "official" kernel, you should be able to make your own changes. If you work on kernel development, you should be able to test your changes. If root can't control these things, then who can? Besides, even if root can't change the kernel, the system will still be compromised if an intruder gets root access.
- ravi-delia 6y ago
  You can pretty easily sign your own kernel, it's not just manufacturer discretion.
  - bombcar 6y ago
    Yeah, it's the same as SELINUX - layers of security. I could easily see reasons to have a box that can boot a signed kernel but the signing keys are held by me offline.
- mindslight 6y ago
  The point is that if the owner has chosen to required signature verification to boot, one shouldn't be able to get around this by restoring from a hibernation image. Imagine you as the party who booted the original kernel, and an evil maid as the party injecting the fake hibernation image. The real problem with TPM and its ilk is that keys owned by the manufacturer are baked in, rather than being owner-changeable by some suitable procedure. Overall, local cryptographic integrity does make sense. Remote Attestation is the actual threat to Freedom, but that's a separate discussion.

mjg59 6y ago

There's three things we really want here: 1) Prevent people gaining inappropriate privileges 2) Detect if people have gained inappropriate privileges 3) Prevent those inappropriate privileges form being persisted If we can achieve (1) then (2) and (3) are irrelevant. If we can't, then (2) depends on the kernel being trustworthy (things like IMA and audit can give strong indications of compromise, but if the attacker can get into the kernel then they can just hide themselves), and (3) is much easier for an attacker to undetectably pull off if they can switch out the on-disk kernel.