[PM-5693] CryptoService using memfd_secret on Linux #979
Conversation
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
crates/bitwarden-crypto/src/service/key_store/linux_memfd_secret_impl.rs
Fixed
Show fixed
Hide fixed
crates/bitwarden-crypto/src/service/key_store/linux_memfd_secret_impl.rs
Fixed
Show fixed
Hide fixed
|
No New Or Fixed Issues Found |
dani-garcia
force-pushed
the
ps/secure-crypto-service
branch
from
7e9bd88 to
d7c7c3e
Compare
Otherwise some Drop implementations can crash
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #979 +/- ##
==========================================
- Coverage 58.32% 58.05% -0.27%
==========================================
Files 193 199 +6
Lines 13557 14617 +1060
==========================================
+ Hits 7907 8486 +579
- Misses 5650 6131 +481 ☔ View full report in Codecov by Sentry. |
| [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.
memsec is using windows-sys 0.45, which was causing build errors similar to the ones fixed by #1053.
Using the latest windows-sys 0.59 seems to solve the problem for me. TODO: Open a PR upstream?
dani-garcia
changed the title
dani-garcia
force-pushed
the
ps/secure-crypto-service
branch
from
3157eaa to
f882fb2
Compare
| @@ -23,6 +23,8 @@ 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.
I can't change the MissingKey variant without breaking the code, so for now I'll do this and rename it on the second PR.
| fn insert(&mut self, key_ref: Key, key: Key::KeyValue); | ||
| fn get(&self, key_ref: Key) -> Option<&Key::KeyValue>; | ||
| fn remove(&mut self, key_ref: Key); | ||
| fn clear(&mut self); | ||
|
|
||
| fn retain(&mut self, f: fn(Key) -> bool); |
There was a problem hiding this comment.
suggestion: add some documentation to these functions describing their behavior and use-cases. Admittedly most are pretty self-explanatory, but e.g. retain isn't
🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-5693
📔 Objective
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: #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