[PM-5693] CryptoService using memfd_secret on Linux #7
Conversation
Otherwise some Drop implementations can crash
|
New Issues
|
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #7 +/- ##
==========================================
- Coverage 62.86% 62.23% -0.63%
==========================================
Files 179 185 +6
Lines 12685 13742 +1057
==========================================
+ Hits 7974 8553 +579
- Misses 4711 5189 +478 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
I've taken an initial look at this. I think the general concept is solid, there are some potential areas for improvements.
However the biggest pieces would be:
- Documentation, we need to ensure we write solid documentation on the difference areas and ensure we are clear about how it's intended to be used.
- Improve test coverage, since we're dealing with cryptography we want to be really sure nothing breaks in the future.
| [target.'cfg(not(target_arch = "wasm32"))'.dependencies] | ||
| memsec = { version = "0.7.0", features = [ | ||
| "alloc_ext", | ||
| ], git = "https://github.com/dani-garcia/memsec", rev = "3d2e272d284442637bac0a7d94f76883960db7e2" } |
There was a problem hiding this comment.
We should try and get this merged upstream.
| fn get_mut(&mut self) -> Result<&mut Keys<SymmKeyRef, AsymmKeyRef>> { | ||
| Err(crate::CryptoError::ReadOnlyCryptoStore) | ||
| } |
There was a problem hiding this comment.
Do we still need get_mut if we can't always access it? Or should we expose a different trait which can't use this to get compile time safety.
| @@ -23,6 +23,10 @@ pub enum CryptoError { | |||
| MissingKey(Uuid), | |||
| #[error("The item was missing a required field: {0}")] | |||
| MissingField(&'static str), | |||
| #[error("Missing Key for Ref. {0}")] | |||
| MissingKey2(String), | |||
There was a problem hiding this comment.
MissingKey2 😭 Will this be removed once we remove all usages of the old interfaces?
There was a problem hiding this comment.
Yeah, that's removed in the other PR that starts using this code in the rest of the SDK:
https://github.com/bitwarden/sdk-internal/pull/8/files#diff-3a39fb8ed55a85cd232b4ac7681c85bb81462727f6d311b1a4c33be7c5b7f4ed
I didn't want to update it here to avoid needing to touch up code which was going to need to be updated in the other PR anyway
| // We want to split all the data between available threads, but at the | ||
| // same time we don't want to split it too much if the amount of data is small. | ||
|
|
||
| // In this case, the minimum chunk size is 50. | ||
| let chunk_size = usize::max(1 + data.len() / rayon::current_num_threads(), 50); |
There was a problem hiding this comment.
suggestion: Move this to a function to ensure consistency between both encrypt and decrypt.
There was a problem hiding this comment.
Do we have any documentation for why we need to implement our own slice vs using built in?
| ) -> Result<Output, crate::CryptoError>; | ||
| } | ||
|
|
||
| // Basic Encryptable/Decryptable implementations to and from bytes |
| // inside the CryptoServiceContext. The read-write access should only be used internally | ||
| // in this crate to avoid users leaving the crypto store in an inconsistent state, | ||
| // but for the moment we have some operations that require access to it. | ||
| pub trait GlobalAccessMode<'a, SymmKeyRef: SymmetricKeyRef, AsymmKeyRef: AsymmetricKeyRef> { |
There was a problem hiding this comment.
question: Is there a purpose in making the types generic?
There was a problem hiding this comment.
So initially, the way I thought about the CryptoContext was that it would have a read-only view of the global keys, and a read-write exclusive store to deal with intermediate and ephemeral keys, like cipher keys.
The reason to enforce the read-only view was that it would allow you to parallelize decryption by just creating a bunch of independent contexts. This works great for decryptable/encryptable implementations, which don't have to modify the global keys ever.
What I didn't initially consider was that this context concept would also be useful when initializing the global keys themselves. For example, the context provides utilities for decrypting the org keys directly into the key store, but of course, as-is, the context can't store things into the global store.
So to avoid duplicating the context code, I made the Context generic over the read/read-write status over the global store. This is a bit awkward and leads to strange things like the always-failing get_mut you mention here: #7 (comment). I'm now thinking it would have been simpler with an enum GlobalAccessMode { ReadOnly(RWLockReadGuard), ReadWrite(RWLockWriteGuard) }
I think this change, combined with the local key refs not being a separate type and instead being a runtime check, makes things a bit weird. I want to look into improving the story around local keys but that's another thing.
| use key_store::KeyStore; | ||
|
|
||
| #[derive(Clone)] | ||
| pub struct CryptoService<SymmKeyRef: SymmetricKeyRef, AsymmKeyRef: AsymmetricKeyRef> { |
There was a problem hiding this comment.
question: Should this be called a service, or something more generic like key store? I think we can drop the references to service.
There was a problem hiding this comment.
We're already using KeyStore for the trait that only deals with the key storage, so we'd need to rename that or choose a different name.
But yeah I'm happy to rename it if we have a better name.
| pub struct CryptoService<SymmKeyRef: SymmetricKeyRef, AsymmKeyRef: AsymmetricKeyRef> { | ||
| // We use an Arc<> to make it easier to pass this service around, as we can | ||
| // clone it instead of passing references | ||
| key_stores: Arc<RwLock<Keys<SymmKeyRef, AsymmKeyRef>>>, |
There was a problem hiding this comment.
question: This seems to be one instance of Keys, is there a reason to use a plural name here?
There was a problem hiding this comment.
I think I've refactored this a couple of times and this was from a time where things were structured differently, I can change it.
| use key_store::KeyStore; | ||
|
|
||
| #[derive(Clone)] | ||
| pub struct CryptoService<SymmKeyRef: SymmetricKeyRef, AsymmKeyRef: AsymmetricKeyRef> { |
There was a problem hiding this comment.
question: We define a Keys struct which essentially acts as the KeyStore. Would it be a cleaner interface to define a KeyStore trait which both CryptoService and Keys implements, and CryptoService simply forwards calls to the inner store.
🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-5693
📔 Objective
Migrated from bitwarden/sdk#979
I've been looking into using
memfd_secretto protect keys in memory on Linux.The
memfd_secretAPI is similar to malloc in that we get some memory range allocated for us, but this memory is only visible to the process that has access to the file descriptor, which should protect us from any memory dumping from anything other than a kernel driver.https://man.archlinux.org/man/memfd_secret.2.en
Using this requires changing how we store keys, so this is the perfect moment to go through removing the raw keys from the API surface.
Changes
KeyReftrait andSymmetricKeyRef/AsymmetricKeyRefsubtraits to represent the key types. Also a small macro to quickly implement them.KeyRefimplementations are user defined types that implementsEq+Hash+Copy, and don't contain any key materialKeyEncryptable/KeyDecryptableare nowDecryptable/Encryptable, and instead of taking the key as parameter, they take aCryptoServiceContextand aKeyRef. This way keys are never exposed to the clients.KeyLocatortrait is replaced byUsesKey. This trait only returns theKeyRefof the key required to decrypt it, instead of fetching the key itself.KeyStoretrait, with some simple CRUD methods. We have two implementations, one based onmemfd_secretfor Linux, and another one based on a Rust boxed slice, that also appliesmlockif possible.mlockandmemfd_secretapply their protection over a specified memory area, we need a Rust data structure that is laid out linearly and also doesn't reallocate by itself. Also becausememfd_secretallocates the memory for us, we can't use a std type like Vec (reason is the Vec must be allocated by the Rust allocator [ref]). This basically only leaves us with a Rust slice, on top of which we'd need to implement insert/get/delete. To allow for reuse and easier testing I've createdSliceKeyStore, which implements the CRUD methods from theKeyStoretrait on top of a plain slice. Then the actualmlockandmemfd_secretimplementations just need to implement a trait casting their data to a slice. The data is stored as a slice ofOption<(KeyRef, KeyMaterial)>, and the keys are unique and sorted in the slice for easier lookups.CryptoService, which contains theKeyStores and some encrypt/decrypt utility functions. From aCryptoServiceyou can also initialize aCryptoServiceContextCryptoServiceContextcontains a read only view of the keys inside theCryptoService, plus a read-write ephemeral key store, for use byDecryptable/Encryptableimplementations when they need to temporarily store some keys (Cipher keys, attachment keys, send keys...).Migrated the codebase to use these changes in a separate PR: bitwarden/sdk#1117
📸 Screenshots
⏰ Reminders before review
team
🦮 Reviewer guidelines
:+1:) or similar for great changes:memo:) or ℹ️ (:information_source:) for notes or general info:question:) for questions:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmedissue and could potentially benefit from discussion
:art:) for suggestions / improvements:x:) or:warning:) for more significant problems or concerns needing attention:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt:pick:) for minor or nitpick changes