Skip to content

Add KeyringMode unit property to fix cryptsetup key caching#6832

Merged
keszybz merged 2 commits intosystemd:masterfrom
poettering:keyring-mode
Sep 15, 2017
Merged

Add KeyringMode unit property to fix cryptsetup key caching#6832
keszybz merged 2 commits intosystemd:masterfrom
poettering:keyring-mode

Conversation

@poettering
Copy link
Copy Markdown
Member

Mostly an implementation of what was proposed here:

#6286 (comment)

I am not sure if this fixes all the key caching issues reported. @eworm-de can I bribe you into testing this PR and checking if this fixes the caching issues for you properly?

keszybz
keszybz previously approved these changes Sep 15, 2017
Copy link
Copy Markdown
Member

@keszybz keszybz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks superficially OK, but I think the keyring should be called "keyring" everywhere, and the mode should be "KeyringMode" [https://en.wikipedia.org/wiki/Keyring_(cryptography)].

<row>
<entry>@keyring</entry>
<entry>Kernel keyring access (<citerefentry project='man-pages'><refentrytitle>keyctl</refentrytitle><manvolnum>2</manvolnum></citerefentry> and related calls)</entry>
<entry>Kernel key ring access (<citerefentry project='man-pages'><refentrytitle>keyctl</refentrytitle><manvolnum>2</manvolnum></citerefentry> and related calls)</entry>
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"keyring" is a valid word nowadays.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm, i checked merriem webster specifically, and it insisted on "key ring"... But i figure if it's "keyring" according to wikipedia in respect to cryptography, i figure that's fine too

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I think it'd be confusing. Internally in the code we have keyring in various places, so adding key_ring in others is inconsistent.

uid_t saved_uid;
gid_t saved_gid;

/* Acquiring a reference to the user keyring is nasty. We briefly change identity in oder to get things
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

typo

@poettering
Copy link
Copy Markdown
Member Author

force pushed a new version that makes the KeyRing → Keyring change, as @keszybz suggested (and the typo fix too).

Please have another look!

@keszybz keszybz changed the title Add new KeyRingMode unit property in order to fix cryptsetup key caching Add KeyringMode unit property to fix cryptsetup key caching Sep 15, 2017
@keszybz
Copy link
Copy Markdown
Member

keszybz commented Sep 15, 2017

Whoa, isn't this missing some .gperf changes?

@keszybz keszybz added the reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks label Sep 15, 2017
@keszybz keszybz dismissed their stale review September 15, 2017 14:24

need to review again

@poettering
Copy link
Copy Markdown
Member Author

hmm, indeed. not sure where that commit got lost

…yring setup

Usually, it's a good thing that we isolate the kernel session keyring
for the various services and disconnect them from the user keyring.
However, in case of the cryptsetup key caching we actually want that
multiple instances of the cryptsetup service can share the keys in the
root user's user keyring, hence we need to be able to disable this logic
for them.

This adds KeyringMode=inherit|private|shared:

    inherit: don't do any keyring magic (this is the default in systemd --user)
    private: a private keyring as before (default in systemd --system)
    shared: the new setting
…yring

We want that cryptsetup can cache keys between multiple invocations, and
it does so via the root user's user keyring, hence let's share it among
services.

Replaces: systemd#6286
@poettering
Copy link
Copy Markdown
Member Author

somehow the unit file change got lost in my rebase orgy. Readded that stuff from scracth now. Please have a look.

keszybz added a commit to keszybz/systemd that referenced this pull request Sep 15, 2017
@keszybz keszybz added ci-failure-appears-unrelated good-to-merge/waiting-for-ci 👍 PR is good to merge, but CI hasn't passed at time of review. Please merge if you see CI has passed and removed reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks labels Sep 15, 2017
@keszybz
Copy link
Copy Markdown
Member

keszybz commented Sep 15, 2017

× xenial-i386 fails in networkd-test.py again, most likely unrelated.

@keszybz
Copy link
Copy Markdown
Member

keszybz commented Sep 15, 2017

I booted my notebook with this, everything seems to work nicely.

@keszybz keszybz removed the good-to-merge/waiting-for-ci 👍 PR is good to merge, but CI hasn't passed at time of review. Please merge if you see CI has passed label Sep 15, 2017
@keszybz keszybz merged commit 3d7d3cb into systemd:master Sep 15, 2017
@eworm-de
Copy link
Copy Markdown
Contributor

Looks good, thanks a lot!
My code works with just little modifications.


r = -errno;

(void) setreuid(saved_uid, -1);
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The setreiud(2) manpage includes a warning against calling setreuid(2) without checking the error return:

       Note: there are cases where setreuid() can fail even when the
       caller is UID 0; it is a grave security error to omit
       checking for a failure return from setreuid().

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, this is a fatal error path already. Generally, when an error path itself results in another error you're fucked. In this case we do the best we can, and make sure to return the first error that happens and the caller will eventually exit due to this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Development

Successfully merging this pull request may close these issues.

4 participants