And that’s why I said “not a security mechanism”. Attestation is for protecting against actors with local hardware access. I have FDE and door locks for that already.
Given secure boot and a TPM you can remotely attest, using your own keys, that the system booted up to a known good state. What exactly that means though depends entirely on what you configured the image to contain.
> it won’t protect from malicious updates to configuration files
It will if you include the verified correct state of the relevant config file in a merkel tree.
> It won’t let me run arbitrary binaries (putting a nail to any local development), or if it will - it would be a temporary security theater (as attackers would reuse the same processes to sign their malware).
Shouldn't it permit running arbitrary binaries that you have signed? That places the root of trust with the build environment.
Now if you attempt to compile binaries and then sign them on the production system yeah that would open you up to attack (if we assume a process has been compromised at runtime). But wasn't that already the case? Ideally the production system should never be used to sign anything. (Some combination of SGX, TPM, and SEV might be an exception to that but I don't know enough to say.)
> Attestation is for protecting against actors with local hardware access. I have FDE and door locks for that already.
If you remotely boot a box sitting in a rack on the other side of the world how can you be sure it hasn't been compromised? However you go about confirming it, isn't that what attestation is?
Production servers are a whole different story - it's usually not my hardware to begin with. But given how things are mostly immutable those days (shipped as images rather than installed the old-fashioned sysadmin way), I'm not really sure what to think of it...
Granted these technologies can also be abused. But that involves running third party binaries that require SGX or other DRM measures before they will unlock or decrypt content or etc. Or querying a security element to learn who signed the image that was originally booted. Devices that support those things are already widespread. I don't think that's what this project is supposed to be. (Although I could always be wrong. There's almost no detail provided.)
This is for example dm-verity (e.g. `/usr/` is an erofs partiton with matching dm-verity). Lennart always talks about either having files be RW (backed by encryption) or RX (backed by kernel signature verification).
That is impossible.
"secure" devices get silently tampered with everyday.
You can never guarantee that.
Of course you can already do the above with secure boot coupled with a CPU that implements an fTPM. So I can't speak to the value of this project specifically, only build and boot integrity in general. For example I have no idea what they mean by the bullet "runtime integrity".