Add support for encrypted credentials#19995
Conversation
|
This pull request introduces 2 alerts when merging 39c85df into b905f3b - view on LGTM.com new alerts:
|
|
Nicea feature! And I have a use case for this coming up, so yay! Will look in detail tomorrow, in the meanwhile the CI is unhappy: |
|
This pull request introduces 2 alerts when merging 6f4ea2e into b905f3b - view on LGTM.com new alerts:
|
|
This pull request introduces 2 alerts when merging abfe702 into b905f3b - view on LGTM.com new alerts:
|
|
This pull request introduces 2 alerts when merging 1cbae50 into b905f3b - view on LGTM.com new alerts:
|
|
Added docs and test. This is ready for review I guess. Post 249 material of course. |
|
This pull request introduces 2 alerts when merging c2c4253 into 6222acc - view on LGTM.com new alerts:
|
|
This pull request introduces 2 alerts when merging 1da349a into b80ef40 - view on LGTM.com new alerts:
|
|
This pull request introduces 2 alerts when merging 09c9453 into 86e24d6 - view on LGTM.com new alerts:
|
|
This pull request introduces 2 alerts when merging 9806867 into eb70d94 - view on LGTM.com new alerts:
|
keszybz
left a comment
There was a problem hiding this comment.
I like this a lot. It's genius in its simplicity and versatility.
I think we shouldn't merge this before v249 though, to give it a bit of time to settle. I'll do a proper review later.
Maybe we should ask Github to enhance CoPilot to create those docs for us! |
|
This pull request introduces 2 alerts when merging 556b682 into 66e6128 - view on LGTM.com new alerts:
|
|
This pull request introduces 2 alerts when merging 47b2b66 into f627855 - view on LGTM.com new alerts:
|
…rks without "khash" So, as it turns out AF_ALG is turned off in a lot of kernels/container environments, including our CI. Hence, if we link against OpenSSL anyway, let's just use that client side. It's also faster. One of those days we should drop the khash code, and ust use OpenSSL, once the licensing issues are resolved.
…om journalctl This moves the code for setting chattr file attributes appropriate for "secrets" files from journalctl into generic chattr-util.c code so that we can use it elsewhere. Also, let's reuse the "bitwise" logic already implemented in the chattr code, instead of doing it again.
This is preparation for adding encryption support to the credentials logic, and we thus would like to add more deps. Let's hence move things from src/basic/ to src/shared, so that we can rely on the OpenSSL utilities already in src/shared.
|
This pull request introduces 2 alerts when merging 199b097 into 105a424 - view on LGTM.com new alerts:
|
|
|
||
| * credentials system: | ||
| - acquire from kernel command line | ||
| - acquire from EFI variable? |
There was a problem hiding this comment.
I like this idea a lot, I have to support a number of boards that don't have dedicated TPM's where it would be quite handy to be able to bind authentication credentials to motherboards, this could be used for a number of use cases such as:
- ensuring that one can't accidentally duplicate authentication credentials when cloning hard drives by forcing a regeneration of credentials if decryption fails due to a missing EFI variable
- simplify secure hard drive reuse/resale during upgrade cycles in cases where the hard disks are replaced with their associated motherboards being kept in operation
- providing a clean transition path to more secure TPM based credential storage
There was a problem hiding this comment.
would be delighted to review a patch for this
There was a problem hiding this comment.
Hmm, I wonder...would this actually be possible to do already by just redirecting /var/lib/systemd/credentials.secret to something in /sys/firmware/efi/efivars?
Not sure how best/where to implement this though, would we want to have this integrated with systemd-boot in some way or just pull it from efivars once booted?
This adds LoadCredentialEncrypted= and SetCredentialEncrypted=, similar in style to LoadCredential=/SetCredential=, but taking encrypted credentials. These credentials are symmetrically encrypted with a TPM2 key and/or a key stored in /var/lib/systemd/, and only decrypted the instant a service needing them is started.
This has the benefit that credentials can remain encrypted on disk, until they are needed. It also has the benefit that these credentials can be stored on untrusted storage (e.g. inside an initrd or an ESP) and still be used reasonably securely. Moreover, to steal a credential it is no longer sufficient to copy the storage disk, but the TPM2 chip has be stolen too. Additionally, it has the benefit that the keys can be pasted directly inside of unit files this way. Unit files are considered to be readable by unprivileged users after all, but if any embedded credentials are encrypted they aren't compromised by this.
Focus is on making it trivially easy to bind credentials to the TPM2, but provide a reasonably secure fallback in environments where TPM2 is not available.
This adds a tool "systemd-creds" for encrypting/decrypting the credentials easily.
Docs and integration tests still missing.