Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[PM-5693] CryptoService using memfd_secret on Linux #7

Open
wants to merge 42 commits into
base: main
Choose a base branch
from

Conversation

dani-garcia
Copy link
Member

🎟️ Tracking

https://bitwarden.atlassian.net/browse/PM-5693

📔 Objective

Migrated from bitwarden/sdk#979

I've been looking into using memfd_secret to protect keys in memory on Linux.

The memfd_secret API 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

  • Added a KeyRef trait and SymmetricKeyRef/AsymmetricKeyRef subtraits to represent the key types. Also a small macro to quickly implement them. KeyRef implementations are user defined types that implements Eq+Hash+Copy, and don't contain any key material
  • KeyEncryptable/KeyDecryptable are now Decryptable/Encryptable, and instead of taking the key as parameter, they take a CryptoServiceContext and a KeyRef. This way keys are never exposed to the clients.
  • KeyLocator trait is replaced by UsesKey. This trait only returns the KeyRef of the key required to decrypt it, instead of fetching the key itself.
  • Created a KeyStore trait, with some simple CRUD methods. We have two implementations, one based on memfd_secret for Linux, and another one based on a Rust boxed slice, that also applies mlock if possible.
  • Because both mlock and memfd_secret apply 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 because memfd_secret allocates 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 created SliceKeyStore, which implements the CRUD methods from the KeyStore trait on top of a plain slice. Then the actual mlock and memfd_secret implementations just need to implement a trait casting their data to a slice. The data is stored as a slice of Option<(KeyRef, KeyMaterial)>, and the keys are unique and sorted in the slice for easier lookups.
  • Created CryptoService, which contains the KeyStores and some encrypt/decrypt utility functions. From a CryptoService you can also initialize a CryptoServiceContext
  • A CryptoServiceContext contains a read only view of the keys inside the CryptoService, plus a read-write ephemeral key store, for use by Decryptable/Encryptable implementations 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

  • Contributor guidelines followed
  • All formatters and local linters executed and passed
  • Written new unit and / or integration tests where applicable
  • Protected functional changes with optionality (feature flags)
  • Used internationalization (i18n) for all UI strings
  • CI builds passed
  • Communicated to DevOps any deployment requirements
  • Updated any necessary documentation (Confluence, contributing docs) or informed the documentation
    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 confirmed
    issue 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

Copy link
Contributor

Logo
Checkmarx One – Scan Summary & Details59dfd02d-90cc-413e-a390-0a461a106165

New Issues

Severity Issue Source File / Package Checkmarx Insight
MEDIUM Unpinned Actions Full Length Commit SHA /publish-rust-crates.yml: 76 Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps...
MEDIUM Unpinned Actions Full Length Commit SHA /version-bump.yml: 44 Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps...
MEDIUM Unpinned Actions Full Length Commit SHA /publish-internal.yml: 61 Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps...
MEDIUM Unpinned Actions Full Length Commit SHA /release-swift.yml: 136 Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps...
MEDIUM Unpinned Actions Full Length Commit SHA /publish-internal.yml: 67 Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps...
MEDIUM Unpinned Actions Full Length Commit SHA /build-swift.yml: 95 Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps...
MEDIUM Unpinned Actions Full Length Commit SHA /release-swift.yml: 73 Pinning an action to a full length commit SHA is currently the only way to use an action as an immutable release. Pinning to a particular SHA helps...

Copy link

codecov bot commented Oct 22, 2024

Codecov Report

Attention: Patch coverage is 55.06149% with 475 lines in your changes missing coverage. Please review.

Project coverage is 62.23%. Comparing base (3800954) to head (748ba75).

Files with missing lines Patch % Lines
crates/bitwarden-crypto/src/service/context.rs 0.00% 224 Missing ⚠️
crates/bitwarden-crypto/src/service/mod.rs 0.00% 117 Missing ⚠️
crates/bitwarden-crypto/src/keys/encryptable.rs 0.00% 104 Missing ⚠️
...es/bitwarden-crypto/src/service/key_store/slice.rs 95.89% 22 Missing ⚠️
...crypto/src/service/key_store/implementation/mod.rs 0.00% 8 Missing ⚠️
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.
📢 Have feedback on the report? Share it here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant