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.
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
This TPM stuff is focused on verifying the integrity of the the boot chain. It’s meant to protect against things like replacing GRUB or changing GRUB options in a malicious way. If that stuff is detected, the system won’t boot.
It’s goal is not to prevent malicious changes in userspace, after the system is booted. Protections against malicious userspace modifications must come elsewhere, like SELinux, AppArmor, sandboxed apps, Wayland, etc.
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
What do you mean by vendor here? Initially we were discussing applications doing some sort of system integrity check to decide whether or not the application would run. But now it seems like you are referring to the distro deciding whether or not you are allowed to do things.
But again, these checks are just for the OS and it would not make sense to try and turn this into a DRM-like system when Secure Boot is much better suited for that task.
And distros already control what you can and cannot do by how they choose to build the OS. Lets consider Aeon and Universal Blue.
Aeon is an OS that implements things that Poettering is discussing. Uses TPM to verify the integrity and unlock the disk if everything is fine. It also is immutable, which limits user customization in some ways as part of its philosophy. It discourage OS modifications and encourages use of Flathub and distrobox.
The Universal Blue family of distros does not implement Poettering’s stuff (though there is an option to do so). But it has similar restrictions as Aeon, discourages OS modifications, encourages use of Flathub/Homebrew/Distrobox.
My point is that verifying the boot chain integrity largely does not matter when it comes to user choice. While the two I mention do have restrictions, they are only philosophical, you could build a system that has these boot chain integrity checks and it not immutable. Measured Boot is great for this task because it puts the user is control, you don’t need to worry about the software being signed with some third party’s key to boot.
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
I agree in some respects. I like immutable distros, flatpaks, and sandboxed/containerized stuff, but sometimes you just need to install software on the host, unsandboxed. The big thing is that immutable distros want the OS and software on top to be cleanly separated.
Some say to use Hombrew, which will take up quite a bit of space and will not always work (like SELinux permission issues) and I don’t necessarily like it how puts all its dependencies on your PATH.
Notably, Systemd came up with system extensions. Seems complicated, have never gotten around to using them.
Then I look over at BSD land and their solution is stupidly simple. OS stuff goes into places like /usr/bin while user installed stuff goes into /usr/local/bin. I don’t really see why immutable distros can’t just have a normal package manager but have everything installed to a different place like /usr/local/bin and put that on the PATH.
But how it’s implemented means everything. Google’s play integrity is corrupting because it’s designed to lock vendors in to Google’s proprietary ecosystem. You’re not getting that from this ‘language’ alone, it could be the case but it’s a massive leap at this point.
I do not care if it is connected to proprietary ecosystem or not. The freedom to decide what software am I allowed to run on my PC is important for me though. Any system that limits that freedom is evil by definition.
if unprivileged software can ask the integrity verifier component which private key is used as the integrity root, or what rules does the verifier keep, then it can be used by commercial software (and web browsers) to decide whether they allow running themselves on your computer (or whether you are allowed to watch netflix, or log in to the bank’s or the government’s website)
I do not understand where does your optimism come from? In what little that we do know they describe the exact same system using the exact same wording as google. If they mean some other thing then they should spend a couple of hours and describe how is it different. And before that the worst should be assumed. It is to dangerous to treat it in any other way.
I don’t like to ever assume negative intent without good evidence. I think I’m taking the neutral rather than optimistic view here. If you want me to speculate whether this new company is good or evil, that would just be my speculation; it would depend how they intend to make money out of it, from my gut instinct I can’t say they give me any specific Google vibes yet.
It’s not about the google vibes, it’s that this thing could be standardized and used by several programs and websites.
here’s an example. with google’s integrity system, most phones can not go through attestation. an exception is phones that can run GrapheneOS. but for apps that require attestation, the developers need to change their app so that it accepts valid attestations of systems that use the GrapheneOS key. such apps can decide to keep only accepting google approved systems.
so far it looks like this will work similarly enough that software you run will be able to be picky about what distribution you use.
They haven’t announced anything other than a vague outline of what they’re trying to solve, it could be implemented in so many ways at this point.
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.
This TPM stuff is focused on verifying the integrity of the the boot chain. It’s meant to protect against things like replacing GRUB or changing GRUB options in a malicious way. If that stuff is detected, the system won’t boot.
It’s goal is not to prevent malicious changes in userspace, after the system is booted. Protections against malicious userspace modifications must come elsewhere, like SELinux, AppArmor, sandboxed apps, Wayland, etc.
What do you mean by vendor here? Initially we were discussing applications doing some sort of system integrity check to decide whether or not the application would run. But now it seems like you are referring to the distro deciding whether or not you are allowed to do things.
But again, these checks are just for the OS and it would not make sense to try and turn this into a DRM-like system when Secure Boot is much better suited for that task.
And distros already control what you can and cannot do by how they choose to build the OS. Lets consider Aeon and Universal Blue.
Aeon is an OS that implements things that Poettering is discussing. Uses TPM to verify the integrity and unlock the disk if everything is fine. It also is immutable, which limits user customization in some ways as part of its philosophy. It discourage OS modifications and encourages use of Flathub and distrobox.
The Universal Blue family of distros does not implement Poettering’s stuff (though there is an option to do so). But it has similar restrictions as Aeon, discourages OS modifications, encourages use of Flathub/Homebrew/Distrobox.
My point is that verifying the boot chain integrity largely does not matter when it comes to user choice. While the two I mention do have restrictions, they are only philosophical, you could build a system that has these boot chain integrity checks and it not immutable. Measured Boot is great for this task because it puts the user is control, you don’t need to worry about the software being signed with some third party’s key to boot.
I agree in some respects. I like immutable distros, flatpaks, and sandboxed/containerized stuff, but sometimes you just need to install software on the host, unsandboxed. The big thing is that immutable distros want the OS and software on top to be cleanly separated.
Some say to use Hombrew, which will take up quite a bit of space and will not always work (like SELinux permission issues) and I don’t necessarily like it how puts all its dependencies on your PATH.
Notably, Systemd came up with system extensions. Seems complicated, have never gotten around to using them.
Then I look over at BSD land and their solution is stupidly simple. OS stuff goes into places like /usr/bin while user installed stuff goes into /usr/local/bin. I don’t really see why immutable distros can’t just have a normal package manager but have everything installed to a different place like /usr/local/bin and put that on the PATH.
The language used speaks for itself. We already know what “integrity” means in this context.
This does not seem vague to me. It explicitly states what they are creating.
But how it’s implemented means everything. Google’s play integrity is corrupting because it’s designed to lock vendors in to Google’s proprietary ecosystem. You’re not getting that from this ‘language’ alone, it could be the case but it’s a massive leap at this point.
I do not care if it is connected to proprietary ecosystem or not. The freedom to decide what software am I allowed to run on my PC is important for me though. Any system that limits that freedom is evil by definition.
I’m right with you there, and it’s proprietary software that threatens that, nothing included in this announcement does though.
if unprivileged software can ask the integrity verifier component which private key is used as the integrity root, or what rules does the verifier keep, then it can be used by commercial software (and web browsers) to decide whether they allow running themselves on your computer (or whether you are allowed to watch netflix, or log in to the bank’s or the government’s website)
I do not understand where does your optimism come from? In what little that we do know they describe the exact same system using the exact same wording as google. If they mean some other thing then they should spend a couple of hours and describe how is it different. And before that the worst should be assumed. It is to dangerous to treat it in any other way.
I don’t like to ever assume negative intent without good evidence. I think I’m taking the neutral rather than optimistic view here. If you want me to speculate whether this new company is good or evil, that would just be my speculation; it would depend how they intend to make money out of it, from my gut instinct I can’t say they give me any specific Google vibes yet.
It’s not about the google vibes, it’s that this thing could be standardized and used by several programs and websites.
here’s an example. with google’s integrity system, most phones can not go through attestation. an exception is phones that can run GrapheneOS. but for apps that require attestation, the developers need to change their app so that it accepts valid attestations of systems that use the GrapheneOS key. such apps can decide to keep only accepting google approved systems.
so far it looks like this will work similarly enough that software you run will be able to be picky about what distribution you use.
The intention barely matters. It’s opensource, someone else can do the evil thing.
No. Google’s attestation code is FOSS too.