systemd, kernel keyring and pam_keyinit

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

systemd, kernel keyring and pam_keyinit

Christian Hesse
Hello everybody,

systemd v233 introduced code that makes use of the kernel keyring,
initializing a private keyring for every service and adding a protected key
named "invocation_id". This caused some trouble and we reverted it since then.

Things will change with systemd v235, which adds a new option "KeyringMode="
for units. The values are "inherit", "private" and "shared". The commit [0]
message and changes give the details. Now cryptsetup units are generated with
"KeyringMode=shared", which unbreaks this use case.
Other services that use the kernel keyring and want to share secrets with
other services have to add this as well.

However login sessions where user context is changed can not be handled by
systemd. Looks like we have to update our PAM configurations and add a line
for every service where session is expected to use the kernel keyring:

session optional pam_keyinit.so force revoke

This is required for eCryptfs to function properly.
Any comments on this? Any concerns?

I would like to keep the upstream keyring behavior with release version 235.
Would be nice to have this sorted before.

[0]
https://github.com/systemd/systemd/commit/b1edf4456eabc5951d76b96bc7df2db3feebe669
--
main(a){char*c=/*    Schoene Gruesse                         */"B?IJj;MEH"
"CX:;",b;for(a/*    Best regards             my address:    */=0;b=c[a++];)
putchar(b-1/(/*    Chris            cc -ox -xc - && ./x    */b/42*2-3)*42);}

attachment0 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: systemd, kernel keyring and pam_keyinit

Christian Hesse
Christian Hesse <[hidden email]> on Mon, 2017/09/18 14:29:

> Hello everybody,
>
> systemd v233 introduced code that makes use of the kernel keyring,
> initializing a private keyring for every service and adding a protected key
> named "invocation_id". This caused some trouble and we reverted it since
> then.
>
> Things will change with systemd v235, which adds a new option "KeyringMode="
> for units. The values are "inherit", "private" and "shared". The commit [0]
> message and changes give the details. Now cryptsetup units are generated
> with "KeyringMode=shared", which unbreaks this use case.
> Other services that use the kernel keyring and want to share secrets with
> other services have to add this as well.
>
> However login sessions where user context is changed can not be handled by
> systemd. Looks like we have to update our PAM configurations and add a line
> for every service where session is expected to use the kernel keyring:
>
> session optional pam_keyinit.so force revoke
>
> This is required for eCryptfs to function properly.
> Any comments on this? Any concerns?
>
> I would like to keep the upstream keyring behavior with release version 235.
> Would be nice to have this sorted before.
>
> [0]
> https://github.com/systemd/systemd/commit/b1edf4456eabc5951d76b96bc7df2db3feebe669
So we have a flyspray ticket requesting the same [1] and a report from Mantas
who is already using a setup with pam_keyinit.

As systemd upstream started preparing a release and milestone items are being
resolved [2] I would like to see some progress. Who will do this? Dave, do you
update pambase? Do we add a todo-list containing all packages with pam
configuration files so maintainers can decide on their own whether or not
this is feasible for the package?

[1] https://bugs.archlinux.org/task/54915
[2] https://github.com/systemd/systemd/milestone/12
--
main(a){char*c=/*    Schoene Gruesse                         */"B?IJj;MEH"
"CX:;",b;for(a/*    Best regards             my address:    */=0;b=c[a++];)
putchar(b-1/(/*    Chris            cc -ox -xc - && ./x    */b/42*2-3)*42);}

attachment0 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: systemd, kernel keyring and pam_keyinit

Christian Hesse
Christian Hesse <[hidden email]> on Fri, 2017/09/29 16:30:

> Christian Hesse <[hidden email]> on Mon, 2017/09/18 14:29:
> > Hello everybody,
> >
> > systemd v233 introduced code that makes use of the kernel keyring,
> > initializing a private keyring for every service and adding a protected
> > key named "invocation_id". This caused some trouble and we reverted it
> > since then.
> >
> > Things will change with systemd v235, which adds a new option
> > "KeyringMode=" for units. The values are "inherit", "private" and
> > "shared". The commit [0] message and changes give the details. Now
> > cryptsetup units are generated with "KeyringMode=shared", which unbreaks
> > this use case. Other services that use the kernel keyring and want to
> > share secrets with other services have to add this as well.
> >
> > However login sessions where user context is changed can not be handled by
> > systemd. Looks like we have to update our PAM configurations and add a
> > line for every service where session is expected to use the kernel
> > keyring:
> >
> > session optional pam_keyinit.so force revoke
> >
> > This is required for eCryptfs to function properly.
> > Any comments on this? Any concerns?
> >
> > I would like to keep the upstream keyring behavior with release version
> > 235. Would be nice to have this sorted before.
> >
> > [0]
> > https://github.com/systemd/systemd/commit/b1edf4456eabc5951d76b96bc7df2db3feebe669 
>
> So we have a flyspray ticket requesting the same [1] and a report from
> Mantas who is already using a setup with pam_keyinit.
>
> As systemd upstream started preparing a release and milestone items are
> being resolved [2] I would like to see some progress. Who will do this?
> Dave, do you update pambase? Do we add a todo-list containing all packages
> with pam configuration files so maintainers can decide on their own whether
> or not this is feasible for the package?
>
> [1] https://bugs.archlinux.org/task/54915
> [2] https://github.com/systemd/systemd/milestone/12
Pushed systemd 235.0-1 and pambase 20171006-1 to [testing]...
Let's wait for people to complain. :-p
--
main(a){char*c=/*    Schoene Gruesse                         */"B?IJj;MEH"
"CX:;",b;for(a/*    Best regards             my address:    */=0;b=c[a++];)
putchar(b-1/(/*    Chris            cc -ox -xc - && ./x    */b/42*2-3)*42);}

attachment0 (499 bytes) Download Attachment