It’s not vague at all if you know Poettering and have watched his talks.
This is about securing the boot chain to ensure the integrity of the OS. Ie, someone hasn’t replaced your GRUB with one that looks exactly the same but secretly records your disk password.
It does so in a decentralized way, so anything like Play Integrity would not make sense in the slightest. It’s the TPM chip measuring values and ensuring they match previous recorded values (and the values to change, such as after updates, so after updates are run, the expected values are updated). It’s not a Secureboot-like system that would make it more feasible to have a Play Integrity-like system.
The problem with entire concept is the assertion that “after updates are run, the expected values are updated”. If the administrator can cause the expected values to be updated, you must assume that an attacker who can replace GRUB, in your example, can too, rendering the whole thing ineffective. If the administrator can not cause the expected values to be updated, we’re into an Android like situation, where the vendor decides what you’re allowed to run on your machine. Neither outcome is better than what we have now.
Lennart Pottering has an unfortunate habbit of deciding to fix problems that don’t actually need fixing, then coming up with a vastly overcomplicated solution, takes years to implement, and doesn’t actually provide much or any benefit over what existed before. Any benefit that does occur tends to be the sort of thing that could easily have been added to the previous system, but noone had because it wasn’t actually a pressing concern. One need only look at his history with PulseAudio and systemd to see examples of this. He also tends to be quite rude and dismissive to anyone questioning him, or pointing out architectural issues.
It’s not vague at all if you know Poettering and have watched his talks.
This is about securing the boot chain to ensure the integrity of the OS. Ie, someone hasn’t replaced your GRUB with one that looks exactly the same but secretly records your disk password.
It does so in a decentralized way, so anything like Play Integrity would not make sense in the slightest. It’s the TPM chip measuring values and ensuring they match previous recorded values (and the values to change, such as after updates, so after updates are run, the expected values are updated). It’s not a Secureboot-like system that would make it more feasible to have a Play Integrity-like system.
The problem with entire concept is the assertion that “after updates are run, the expected values are updated”. If the administrator can cause the expected values to be updated, you must assume that an attacker who can replace GRUB, in your example, can too, rendering the whole thing ineffective. If the administrator can not cause the expected values to be updated, we’re into an Android like situation, where the vendor decides what you’re allowed to run on your machine. Neither outcome is better than what we have now.
Lennart Pottering has an unfortunate habbit of deciding to fix problems that don’t actually need fixing, then coming up with a vastly overcomplicated solution, takes years to implement, and doesn’t actually provide much or any benefit over what existed before. Any benefit that does occur tends to be the sort of thing that could easily have been added to the previous system, but noone had because it wasn’t actually a pressing concern. One need only look at his history with PulseAudio and systemd to see examples of this. He also tends to be quite rude and dismissive to anyone questioning him, or pointing out architectural issues.