Comment by fc417fc802

I think all of that comes down to being a matter of what precisely you're attesting? So I'm not actually clear what we're talking about here.

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?