Comment by fc417fc802

Comment by fc417fc802 4 days ago

The value is being able to easily and robustly verify that my device hasn't been compromised. Binding disk encryption keys to the TPM such that I don't need to enter a password but an adversary still can't get at the contents without a zero day.

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".

NekkoDroid 4 days ago

> For example I have no idea what they mean by the bullet "runtime integrity".

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).

Reply View 0 replies

drdaeman 4 days ago

I don’t think attestation can provide such guarantees. To best of my understanding, it won’t protect from any RCE, and it won’t protect from malicious updates to configuration files. 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). IDSes are sufficient for this purpose, without negative side effects.

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.

Reply View 3 replies

fc417fc802 4 days ago

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?

Reply View | 2 replies
- drdaeman 4 days ago
  
  Well, maybe we're talking about different things, because I've asked from a regular GNU/Linux user perspective. That is, I have my computers and I'm concerned I would lose my freedoms to use them as I wish, because this attestation would be adopted and become de-facto mandatory if I ever want to do something online. Just like what happened to mobile, and what's currently slowly happening to other desktop OSes.
  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...
  
  Reply View | 1 reply
  
  fc417fc802 4 days ago
  
  You originally asked what the value proposition for a regular (non-corporate) user was. Then you raised some objections to my answer (or at least so I thought).
  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.)
  
  Reply View | 0 replies

giant_loser a day ago

> The value is being able to easily and robustly verify that my device hasn't been compromised.

That is impossible.

"secure" devices get silently tampered with everyday.

You can never guarantee that.

Reply View 0 replies