search

TritonDataCenter / rfd

Requests for Discussion
Mozilla Public License 2.0
261 stars 77 forks source link

RFD 169 Encrypted kernel crash dump #131

Open bcantrill opened 5 years ago

bcantrill commented 5 years ago

This is an issue to discuss RFD 169 Encrypted kernel crash dump; comments welcome!

danmcd commented 5 years ago

You have an HMAC but only over the first N bytes to reject bad keys. Using a cipher without some sort of packet integrity may enable self-healing block-splicing attacks. Now ChaCha20 isn't CBC, it's CTR, BUT even CTR-mode ciphers need some sort of integrity protection. In SSL, ChaCha20 is paired with Poly1305. Poly1305 has ChaCha20 properties, as it comes from DJB as well.

bcantrill commented 5 years ago

Is the concern that the dump might be tampered with? We're definitely not trying to make the dump tamperproof -- we're trying to prevent it from being seen in cleartext by the attacker.

rmustacc commented 5 years ago

Thanks for putting this together, in general, it all looks good. I agree that the treat vector that we're worried about isn't the dump on the dump device being rewritten right now, but one of just the security of the data. If someone else has maliciously changed the dump device contents, that seems much more problematic. However, we do have the algorithm version in the header, so that allows us to deal with that as necessary.

One question that I have is do we have to have it be the case that if we have an older dump header version we can't compress this? It seems like if we have systems that are in that case, rather than have to find the old savecore, the new savecore could know how to handle the differences between the two versions as they don't seem that big. While it does complicate the userland implementation, it shouldn't impact the actual dump path.

danmcd commented 5 years ago

If tamper-proofing is not a concern, that needs to be documented as such. Others will notice encryption-with-no-integrity and get their reflexes triggered. Please be ready to address it. I may even be missing reasons why it's important beyond tamper-resistance, but I'm pretty sure you don't have to worry about it for tampering reasons (at least in the short-and-medium-term).

rzezeski commented 5 years ago

(there is currently no way to disable dump encryption once enabled).

I don't follow this sentence. If I enable encrypted dump on my machine with dumpadm -k ..., I can never disable it in the future? I understand that once a particular core is encrypted the only way I'm reading it is by decrypting it with the correct key; but it seems you are saying that once you enable encrypted dump on a box there is no going back. That is, I can't later disable encrypted dump for future crashes. If that's the case, I don't understand the reasoning.

Also, what about changing the key? I imagine you can just rerun dumpadm -k? If so, might want to call that out explicitly.

bcantrill commented 5 years ago

I have updated the RFD to address @danmcd's concerns (calling out that this is not to prevent tampering) as well as to change the implementation to allow for spontaneous upgrades.

bcantrill commented 5 years ago

@rzezeski: There is no way to disable encryption without rebooting -- I'll clarify both the RFD and the docs.