5 ms·

Maintaining the Kernel's Web of Trust

58 points by chmaynard 7y ago

carapace 7y ago
Just a friendly reminder: this is all moot due to ME and ilk. https://en.wikipedia.org/wiki/Intel_Management_Engine https://en.wikipedia.org/wiki/Intel_Management_Engine https://en.wikipedia.org/wiki/AMD_Secure_Technology https://en.wikipedia.org/wiki/AMD_Secure_Technology
- mcpherrinm 7y ago
  The integrity of the Linux source code still matters whether or not you trust your hardware vendor. Linux runs on more platforms than those two as well.
  - carapace 7y ago
    Okay, relatively moot. Apologies for the snark, but I feel it's important to keep in mind in discussions of trust and security the enclosing scope or context. You can't trust the "integrity of the Linux source code" if you are checking it with compromised hardware, or running it on compromised hardware. > Linux runs on more platforms than those two as well. I am not a security specialist, just a plain ol' paranoiac, but at this point in history, given what we've seen and heard so far, I would bet most platforms are compromised hardware. I don't really have anything more constructive to add so I'll shut up now.
    - GhettoMaestro 7y ago
      > Apologies for the snark, but I feel it's important to keep in mind in discussions of trust and security the enclosing scope or context. You can't trust the "integrity of the Linux source code" if you are checking it with compromised hardware, or running it on compromised hardware. You are incorrect in this instance. The topic at hand is ensuring software integrity. Your scope of analysis is what I'll call "full-stack integrity" (hardware, firmware, software, etc).
      - carapace 7y ago
        I'm pointing out that ensuring software integrity is a kind of toy or game in a world where the hardware is already "powned" by someone else. People aren't computing cryptographic checksums over the linux kernel by hand. The phrase "security theatre" is probably overused, but from my POV it would seem to apply here.
        GhettoMaestro 7y ago
        Point it out all you want -- it is irrelevant to the discussion at hand. If said discussion was asserting integrity at a hardware level, you would have a point. But it doesn't do that. There is a reason it is narrowly prescriptive.
- acdha 7y ago
  This is not relevant to this discussion: it's like someone announced that they were buying better locks for their house and you're going “this is all moot because someone could just pull the roof off”.
  - carapace 7y ago
    More like the discussion isn't relevant to reality. The house is constantly being renovated and repaired, including the locks, doors, hinges, and every knob and button, by a lot of people, some of whom are even actual contractors, and now a few of those have ID badges. Meanwhile, in Ecuador... (massive database leak ~20M people's data). That's just this morning.
pmoriarty 7y ago
From the comment thread in that article: "I have considered running a non-connected SKS instance, but at this point in time everyone seems to consider SKS as pretty much dead -- it's not maintained and nobody is willing to step up or so much as touch it due to any number of reasons (largely, because OCaml is just too esoteric)." I wonder if they've tried reaching out to the OCaml community. I'd be surprised if there weren't people in it that would be happy to step up to help, were they aware of the need and its importance to Linux kernel development. They could also try actually paying someone to maintain it. As the article notes, the Linux kernel development ecosystem is no longer staffed fully by volunteers. There's a lot of corporate money in it now, including big contributions from the likes of IBM and Redhat. They could certainly afford to hire someone to take on this responsibility, if it was deemed necessary.
- watt 7y ago
  Here's discussion from the time it was mentioned previously: https://news.ycombinator.com/item?id=20312826 https://news.ycombinator.com/item?id=20312826
neilv 7y ago
> But, to avoid signature attacks, only signatures made with other keys stored in the repository are retained; that is sufficient to build the web of trust while eliminating the results of any signature spamming that might have taken place. I didn't understand how this alone is sufficient to prevent signature spamming, once a single compromised or bad-actor signature is in the repo. "https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/README.rst" https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/... suggests a bit different process, which currently seems to require manual importing of individual signatures into one's keyring. And the automated updating of user's keyring is only of such manually-imported signatures. (And the commit from which the updates are taken must be signed by a key that was signed directly by the key of Torvalds or the user.)
cwyers 7y ago
It sounds like the web of trust is an incredibly difficult problem to solve, and also not a problem that the kernel needs to solve. Why do the kernel developers need a decentralized way to verify signing keys?
- bonzini 7y ago
  They don't, that's why they're just putting the keys in a git repo.

58 points by chmaynard 7y ago

Just a friendly reminder: this is all moot due to ME and ilk. https://en.wikipedia.org/wiki/Intel_Management_Engine https://en.wikipedia.org/wiki/Intel_Management_Engine https://en.wikipedia.org/wiki/AMD_Secure_Technology https://en.wikipedia.org/wiki/AMD_Secure_Technology

mcpherrinm 7y ago
The integrity of the Linux source code still matters whether or not you trust your hardware vendor. Linux runs on more platforms than those two as well.
- carapace 7y ago
  Okay, relatively moot. Apologies for the snark, but I feel it's important to keep in mind in discussions of trust and security the enclosing scope or context. You can't trust the "integrity of the Linux source code" if you are checking it with compromised hardware, or running it on compromised hardware. > Linux runs on more platforms than those two as well. I am not a security specialist, just a plain ol' paranoiac, but at this point in history, given what we've seen and heard so far, I would bet most platforms are compromised hardware. I don't really have anything more constructive to add so I'll shut up now.
  - GhettoMaestro 7y ago
    > Apologies for the snark, but I feel it's important to keep in mind in discussions of trust and security the enclosing scope or context. You can't trust the "integrity of the Linux source code" if you are checking it with compromised hardware, or running it on compromised hardware. You are incorrect in this instance. The topic at hand is ensuring software integrity. Your scope of analysis is what I'll call "full-stack integrity" (hardware, firmware, software, etc).
    - carapace 7y ago
      I'm pointing out that ensuring software integrity is a kind of toy or game in a world where the hardware is already "powned" by someone else. People aren't computing cryptographic checksums over the linux kernel by hand. The phrase "security theatre" is probably overused, but from my POV it would seem to apply here.
      - GhettoMaestro 7y ago
        Point it out all you want -- it is irrelevant to the discussion at hand. If said discussion was asserting integrity at a hardware level, you would have a point. But it doesn't do that. There is a reason it is narrowly prescriptive.
acdha 7y ago
This is not relevant to this discussion: it's like someone announced that they were buying better locks for their house and you're going “this is all moot because someone could just pull the roof off”.
- carapace 7y ago
  More like the discussion isn't relevant to reality. The house is constantly being renovated and repaired, including the locks, doors, hinges, and every knob and button, by a lot of people, some of whom are even actual contractors, and now a few of those have ID badges. Meanwhile, in Ecuador... (massive database leak ~20M people's data). That's just this morning.

pmoriarty 7y ago

From the comment thread in that article: "I have considered running a non-connected SKS instance, but at this point in time everyone seems to consider SKS as pretty much dead -- it's not maintained and nobody is willing to step up or so much as touch it due to any number of reasons (largely, because OCaml is just too esoteric)." I wonder if they've tried reaching out to the OCaml community. I'd be surprised if there weren't people in it that would be happy to step up to help, were they aware of the need and its importance to Linux kernel development. They could also try actually paying someone to maintain it. As the article notes, the Linux kernel development ecosystem is no longer staffed fully by volunteers. There's a lot of corporate money in it now, including big contributions from the likes of IBM and Redhat. They could certainly afford to hire someone to take on this responsibility, if it was deemed necessary.

watt 7y ago
Here's discussion from the time it was mentioned previously: https://news.ycombinator.com/item?id=20312826 https://news.ycombinator.com/item?id=20312826

neilv 7y ago

> But, to avoid signature attacks, only signatures made with other keys stored in the repository are retained; that is sufficient to build the web of trust while eliminating the results of any signature spamming that might have taken place. I didn't understand how this alone is sufficient to prevent signature spamming, once a single compromised or bad-actor signature is in the repo. "https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/README.rst" https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/... suggests a bit different process, which currently seems to require manual importing of individual signatures into one's keyring. And the automated updating of user's keyring is only of such manually-imported signatures. (And the commit from which the updates are taken must be signed by a key that was signed directly by the key of Torvalds or the user.)

cwyers 7y ago

It sounds like the web of trust is an incredibly difficult problem to solve, and also not a problem that the kernel needs to solve. Why do the kernel developers need a decentralized way to verify signing keys?

bonzini 7y ago
They don't, that's why they're just putting the keys in a git repo.