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.
Amutable’s approach is a bit vague, but their homepage states: ‘We are building cryptographically verifiable integrity into Linux systems. Every system starts in a verified state and stays trusted over time.’ I read that as starting in a trusted state, presumably via a secureboot verified bootchain, then ensuring that the software running on the OS is in a ‘trusted’ state at all times. In particular, they also say “Build integrity, Boot integrity, Runtime integrity, That’s Amutable” as a tag line, which reinforces the runtime nature of the validation.
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.
I could have been clearer there, I’m referring to OS vendor or distro maintainer. Someone has to be in control of what is “trusted”, and it’s either the administrator of the machine, or the OS vendor. If it’s the administrator of the machine, a malicious actor has an attack route to update the list to include their own malware, and if it’s not the administrator you end up in a Android type situation, where the OS vendor decides.
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.
Secure Boot secures the boot chain, but after that has no part in maintaining the integrity of the system. I agree that it would not make sense to make this some sort of DRM like system, but that does not mean that they will not try. Pottering seems to have the ears of people who are influential enough that even his bad ideas get far more traction than they should.
And distros already control what you can and cannot do by how they choose to build the OS.
Not really, they might make some things naturally harder to do, but they all run the same kernel and can load ELF binaries. Even the most locked down, immutable, system can be made to do things the distro maintainers didn’t expect.
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.
Indeed, verifying the boot chain does not, necessarily, limit what the admin if the machine can do. My concern is that Amutable seem to be seeking to go a lot further than that, and verify what is being executed at runtime. Depending on who controls the keys we may, very well, “need to worry about the software being signed with some third party’s key” if not to boot, then to run.
Amutable’s approach is a bit vague, but their homepage states: ‘We are building cryptographically verifiable integrity into Linux systems. Every system starts in a verified state and stays trusted over time.’ I read that as starting in a trusted state, presumably via a secureboot verified bootchain, then ensuring that the software running on the OS is in a ‘trusted’ state at all times. In particular, they also say “Build integrity, Boot integrity, Runtime integrity, That’s Amutable” as a tag line, which reinforces the runtime nature of the validation.
I could have been clearer there, I’m referring to OS vendor or distro maintainer. Someone has to be in control of what is “trusted”, and it’s either the administrator of the machine, or the OS vendor. If it’s the administrator of the machine, a malicious actor has an attack route to update the list to include their own malware, and if it’s not the administrator you end up in a Android type situation, where the OS vendor decides.
Secure Boot secures the boot chain, but after that has no part in maintaining the integrity of the system. I agree that it would not make sense to make this some sort of DRM like system, but that does not mean that they will not try. Pottering seems to have the ears of people who are influential enough that even his bad ideas get far more traction than they should.
Not really, they might make some things naturally harder to do, but they all run the same kernel and can load ELF binaries. Even the most locked down, immutable, system can be made to do things the distro maintainers didn’t expect.
Indeed, verifying the boot chain does not, necessarily, limit what the admin if the machine can do. My concern is that Amutable seem to be seeking to go a lot further than that, and verify what is being executed at runtime. Depending on who controls the keys we may, very well, “need to worry about the software being signed with some third party’s key” if not to boot, then to run.