Bug#906752: sudo: /etc/pam.d/sudo doesn't create a new keyring session

[Simon Ruggier]

Package: sudo
Version: 1.8.19p1-2.1
Severity: normal
X-Debbugs-CC: Luc Maisonobe <l...@spaceroots.org>
X-Debbugs-CC: Jonas Meurer <jo...@freesources.org>

Dear Maintainer,

sudo's pam config doesn't create a new keyring session for the processes
it spawns. This leads to problems with programs that try to add things
to the keyring, because they try to modify the user's keyring, which
even root doesn't have permission to do. An example of this was
mentioned in this previous bug:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758788#45

> On the first invocation (for cont1_crypt), I got this dialog:
>
> root@marislae:~# cryptdisks_start cont1_crypt
> [[....] Starting crypto disk...[info] cont1_crypt (starting)...
> Caching passphrase for /cont1:  ******
> keyctl_set_timeout: Permission denied
> Error setting timeout on key (2524288), removing
> Caching passphrase for /cont1:  ******
> keyctl_set_timeout: Permission denied
> Error setting timeout on key (612589418), removing
>
> [Here I pressed <ctrl-C> to stop the attempts]
>
> Caching passphrase  for /cont1:  Erreur de lecture de la phrase secrète.
>
>
> I was running the commands from root. I initially logged in to the
> computer from SSH to a regular user, than did "sudo -i" to get root
> access if this matters. As I suspected this may be a problem, I allowed
> root direct SSH access and tried again, login directly to root account,
> this time it worked:
>
> root@marislae:~# cryptdisks_start cont1_crypt
> [....] Starting crypto disk...[info] cont1_crypt (starting)...
> Caching passphrase for /cont1:  ******
> [ ok _crypt (started)...done.
> root@marislae:~# cryptdisks_start cont2_crypt
> [....] Starting crypto disk...[info] cont2_crypt (starting)...
> Using cached passphrase for /cont2.
> [ ok _crypt (started)...done.

It turns out that this works when logged in as root via SSH because this
line in `/etc/pam.d/sshd` sets up a new session keyring for the root
user:

> # Create a new session keyring.
> session    optional     pam_keyinit.so force revoke


The same line is also present in `/etc/pam.d/runuser-l`, so I've been
working around this problem by running cryptdisks_start via `sudo
runuser -l`, as in:

> sudo runuser -l root -c 'cryptdisks_start c1 && cryptdisks_start c2 && # so on'

Given that it's not useful for a process running on the root user to try to manipulate the user's session keyring, I think it would make sense for /etc/pam.d/sudo to force the creation of a new one, or at least for `sudo -i` to force the creation of a new one via a `/etc/pam.d/sudo-i` config file, similar to `runuser -l`.

Thanks,

Simon

-- System Information:
Debian Release: 9.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (102, 'testing'), (101, 'unstable'), (100, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.0-7-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sudo depends on:
ii  libaudit1       1:2.6.7-2
ii  libc6           2.27-5
ii  libpam-modules  1.1.8-3.6
ii  libpam0g        1.1.8-3.6
ii  libselinux1     2.6-3+b3
ii  lsb-base        9.20161125

sudo recommends no packages.

sudo suggests no packages.

-- Configuration Files:
/etc/sudoers [Errno 13] Permission denied: '/etc/sudoers'
/etc/sudoers.d/README [Errno 13] Permission denied: '/etc/sudoers.d/README'

-- no debconf information

[Hilko Bengen]

The pam_keyring(8) manpage advises against adding pam_keyinit

,----
| This module should not, generally, be invoked by programs like su,
| since it is usually desirable for the key set to percolate through to
| the alternate context. The keys have their own permissions system to
| manage this.
`----

However, there's no mentioning of the issue described here.

For what it's worth, RHEL/CentOS 7 ships an /etc/pam.d/sudo which
contains a line.

,----
| session optional pam_keyinit.so revoke
`----

and they also seem to have different intended behavior for interactive
usage – there's a separate /etc/pam.d/sudo-i which contains

,----

| session optional pam_keyinit.so force revoke

`----

Cheers,
-Hilko

[Marc Haber]

X-Debbugs-CC: vor...@debian.org
thanks

So we need to make up our minds whether to follow up the pam_keyinit
maintainers or Red Hat. Maybe the PAM maintainer can comment here?

Greetings
Marc

[Steve Langasek]

On Wed, Feb 02, 2022 at 12:44:44PM +0100, Marc Haber wrote:
> X-Debbugs-CC: vor...@debian.org
> thanks
>
> On Sat, Feb 27, 2021 at 06:38:00PM +0100, Hilko Bengen wrote:
> > The pam_keyring(8) manpage advises against adding pam_keyinit

I guess this is supposed to be pam_keyinit(8) since I do find the text
there.

> > ,----
> > | This module should not, generally, be invoked by programs like su,
> > | since it is usually desirable for the key set to percolate through to
> > | the alternate context. The keys have their own permissions system to
> > | manage this.
> > `----

> > However, there's no mentioning of the issue described here.

> > For what it's worth, RHEL/CentOS 7 ships an /etc/pam.d/sudo which
> > contains a line.

> > ,----
> > | session optional pam_keyinit.so revoke
> > `----

> > and they also seem to have different intended behavior for interactive
> > usage – there's a separate /etc/pam.d/sudo-i which contains

> > ,----
> > | session optional pam_keyinit.so force revoke
> > `----

> So we need to make up our minds whether to follow up the pam_keyinit
> maintainers or Red Hat. Maybe the PAM maintainer can comment here?

I would suggest consulting the maintainers of other packages that currently
ship references to pam_keyinit and try to get a consensus with them. For
example, /etc/pam.d/su-l does reference pam_keyinit in Debian, which seems
like it directly contradicts the above manpage but addresses this exact
issue. I believe debian-devel is the appropriate for venue for such a
discussion.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slan...@ubuntu.com vor...@debian.org

[Marc Haber]

X-Debbugs-Cc: util-...@packages.debian.org

Dear Util-Linux Maintainers,

in sudo, we have currently the situation whether to add calls to
pam_keyinit in our pam configuration files. There is quite a number of
packages doing this, but the pam_keyinit documentation advises "programs
like su" against doing so. However, in Debian, /etc/pam.d/su-l
references pam_keyinit, while /etc/pam.d/su doesn't. On the other hand,
doas doesnt seem to reference pam_keyinit at all.

If sudo goes the way to mimic what su does, we would reference
pam_keyinit in /etc/pam.d/sudo-i which is our form of giving the caller
an interactive session, but not in /etc/pam.d/sudo.

May I ask for you rationale to do things the way you did them for su and
pam_keyinit? Your insights might help us to take a wise decision for
sudo.

On Sat, Feb 27, 2021 at 06:38:00PM +0100, Hilko Bengen wrote:

Thanks for your help, which is greatly appreciated.

Greetings
Marc

--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421

[Chris Hofstaedtler]

Hello Marc,
Hello Andreas (added to CC:),

* Marc Haber <mh+debian...@zugschlus.de> [220206 12:36]:

> in sudo, we have currently the situation whether to add calls to
> pam_keyinit in our pam configuration files. There is quite a number of
> packages doing this, but the pam_keyinit documentation advises "programs
> like su" against doing so. However, in Debian, /etc/pam.d/su-l
> references pam_keyinit, while /etc/pam.d/su doesn't. On the other hand,
> doas doesnt seem to reference pam_keyinit at all.
>
> If sudo goes the way to mimic what su does, we would reference
> pam_keyinit in /etc/pam.d/sudo-i which is our form of giving the caller
> an interactive session, but not in /etc/pam.d/sudo.
>
> May I ask for you rationale to do things the way you did them for su and
> pam_keyinit? Your insights might help us to take a wise decision for
> sudo.

I do not know why this was done for su-l and not su. My speculation
would be that we have inherited the su-l PAM config from Fedora, and
the su PAM config from src:shadow before 2018. Maybe the distinction
is an accident.

Andreas, you worked on the su takeover from src:shadow. Do you have
insights to share?

> On Sat, Feb 27, 2021 at 06:38:00PM +0100, Hilko Bengen wrote:
> > The pam_keyring(8) manpage advises against adding pam_keyinit
> >
> > ,----
> > | This module should not, generally, be invoked by programs like su,
> > | since it is usually desirable for the key set to percolate through to
> > | the alternate context. The keys have their own permissions system to
> > | manage this.
> > `----
> >
> > However, there's no mentioning of the issue described here.
> >
> > For what it's worth, RHEL/CentOS 7 ships an /etc/pam.d/sudo which
> > contains a line.
> >
> > ,----
> > | session optional pam_keyinit.so revoke
> > `----
> >
> > and they also seem to have different intended behavior for interactive
> > usage – there's a separate /etc/pam.d/sudo-i which contains
> >
> > ,----
> > | session optional pam_keyinit.so force revoke
> > `----

I will note that our runuser(-l) PAM config also mirrors this:

runuser:
session optional pam_keyinit.so revoke

runuser-l:

session optional pam_keyinit.so force revoke

It would appear to me that keyutils and pam_keyinit, and most of the
util-linux PAM config originate in Fedora(/RH). The Fedora folks
are probably the ones to ask how all of this is supposed to work.

> Thanks for your help, which is greatly appreciated.

Sorry that I cannot add much useful info here.

Chris

[Marc Haber]

Control: tags -1 help
Control: tags 939357 help
thanks

On Wed, Feb 02, 2022 at 12:44:44PM +0100, Marc Haber wrote:

> So we need to make up our minds whether to follow up the pam_keyinit
> maintainers or Red Hat. Maybe the PAM maintainer can comment here?

For the record, the Red Hat maintainer of pam_keyinit didn't bother
replying. So the next thing is to follow Steve's advice to reach out to
-devel to get consensus. I have currently other things on my plate and
would not like to open just another issue here, I am therefore
postponing this on my personal schedule.

Other team members or people who want to help, please reach out to
-devel at will. Thanks in advance.

Greetings
Marc

[Marc Haber]

Hi Chris,

thanks for trying to help back in February.

I'm coming back to this after being busy with other things.

On Sun, Feb 06, 2022 at 05:09:10PM +0100, Chris Hofstaedtler wrote:
> * Marc Haber <mh+debian...@zugschlus.de> [220206 12:36]:
> > in sudo, we have currently the situation whether to add calls to
> > pam_keyinit in our pam configuration files. There is quite a number of
> > packages doing this, but the pam_keyinit documentation advises "programs
> > like su" against doing so. However, in Debian, /etc/pam.d/su-l
> > references pam_keyinit, while /etc/pam.d/su doesn't. On the other hand,
> > doas doesnt seem to reference pam_keyinit at all.
> >
> > If sudo goes the way to mimic what su does, we would reference
> > pam_keyinit in /etc/pam.d/sudo-i which is our form of giving the caller
> > an interactive session, but not in /etc/pam.d/sudo.
> >
> > May I ask for you rationale to do things the way you did them for su and
> > pam_keyinit? Your insights might help us to take a wise decision for
> > sudo.
>
> I do not know why this was done for su-l and not su. My speculation
> would be that we have inherited the su-l PAM config from Fedora, and
> the su PAM config from src:shadow before 2018. Maybe the distinction
> is an accident.
>
> Andreas, you worked on the su takeover from src:shadow. Do you have
> insights to share?

Andreas, did you read this?

> It would appear to me that keyutils and pam_keyinit, and most of the
> util-linux PAM config originate in Fedora(/RH). The Fedora folks
> are probably the ones to ask how all of this is supposed to work.

Chris,
Can you give me a pointer to whom in Fedora I'm supposed to reach out?

Greetings
Marc

[Andreas Henriksson]

Hello Marc, Chris,

Sorry for my late (and possibly pretty lame) reply.

On Tue, Jul 05, 2022 at 03:17:19PM +0200, Marc Haber wrote:
>
> On Sun, Feb 06, 2022 at 05:09:10PM +0100, Chris Hofstaedtler wrote:
> > * Marc Haber <mh+debian...@zugschlus.de> [220206 12:36]:

[...]

> > > May I ask for you rationale to do things the way you did them for su and
> > > pam_keyinit? Your insights might help us to take a wise decision for
> > > sudo.
> >
> > I do not know why this was done for su-l and not su. My speculation
> > would be that we have inherited the su-l PAM config from Fedora, and
> > the su PAM config from src:shadow before 2018. Maybe the distinction
> > is an accident.
> >
> > Andreas, you worked on the su takeover from src:shadow. Do you have
> > insights to share?
>
> Andreas, did you read this?

[...]

I have a very bad memory which is why I try to write down as much as
possible in bug reports, commit messages, etc to leave hints for my
future self. I need to dig to figure things out myself, but I think the
above description is basically correct.

(If there's any message from me that you have a problem with
interpretting what it means, please point me to it and I can try to
interpret my own bad grammar to figure out what I tried to write.)

Regards,
Andreas Henriksson

[Chris Hofstaedtler]

Hi Marc,

* Marc Haber <mh+debian...@zugschlus.de> [220705 15:53]:

> I'm coming back to this after being busy with other things.
>
> On Sun, Feb 06, 2022 at 05:09:10PM +0100, Chris Hofstaedtler wrote:
> > * Marc Haber <mh+debian...@zugschlus.de> [220206 12:36]:
> > > in sudo, we have currently the situation whether to add calls to
> > > pam_keyinit in our pam configuration files. There is quite a number of
> > > packages doing this, but the pam_keyinit documentation advises "programs
> > > like su" against doing so. However, in Debian, /etc/pam.d/su-l
> > > references pam_keyinit, while /etc/pam.d/su doesn't. On the other hand,
> > > doas doesnt seem to reference pam_keyinit at all.
> > >
> > > If sudo goes the way to mimic what su does, we would reference
> > > pam_keyinit in /etc/pam.d/sudo-i which is our form of giving the caller
> > > an interactive session, but not in /etc/pam.d/sudo.
> > >
> > > May I ask for you rationale to do things the way you did them for su and
> > > pam_keyinit? Your insights might help us to take a wise decision for
> > > sudo.
> >
> > I do not know why this was done for su-l and not su. My speculation
> > would be that we have inherited the su-l PAM config from Fedora, and
> > the su PAM config from src:shadow before 2018. Maybe the distinction
> > is an accident.

[..]

> > It would appear to me that keyutils and pam_keyinit, and most of the
> > util-linux PAM config originate in Fedora(/RH). The Fedora folks
> > are probably the ones to ask how all of this is supposed to work.
>
> Chris,
> Can you give me a pointer to whom in Fedora I'm supposed to reach out?

Well, the pam_keyinit man page says it was written by David Howells
<dhow...@redhat.com>, but I don't know if he is still working on
it.

This openSUSE bug seems to touch on related questions:
https://bugzilla.suse.com/show_bug.cgi?id=1081947

Unfortunately the only real doc appears to be the man page :-|

Chris

[Marc Haber]

On Thu, Jul 14, 2022 at 12:20:48PM +0200, Chris Hofstaedtler wrote:
> Well, the pam_keyinit man page says it was written by David Howells
> <dhow...@redhat.com>, but I don't know if he is still working on
> it.

I reached out to that address a few months ago, they didnt bother
replying.

> This openSUSE bug seems to touch on related questions:
> https://bugzilla.suse.com/show_bug.cgi?id=1081947

Lesson learned: The major distributions ALL do not know what they're
doing, they're blindly copying from each other. And nobody cares.

[Chris Hofstaedtler]

* Marc Haber <mh+debian...@zugschlus.de> [220714 14:10]:

> On Thu, Jul 14, 2022 at 12:20:48PM +0200, Chris Hofstaedtler wrote:
> > Well, the pam_keyinit man page says it was written by David Howells
> > <dhow...@redhat.com>, but I don't know if he is still working on
> > it.
>
> I reached out to that address a few months ago, they didnt bother
> replying.
>
> > This openSUSE bug seems to touch on related questions:
> > https://bugzilla.suse.com/show_bug.cgi?id=1081947
>
> Lesson learned: The major distributions ALL do not know what they're
> doing, they're blindly copying from each other. And nobody cares.

Yes, and I think in this case nobody really knows what the expected
behaviour is.
Judging by the man page, su, runuser, sudo should probably NOT
invoke pam_keyinit, expect if run with a flag simulating login
(su/runuser -l, sudo -i?).

As we have seen before, there's also a "force" flag, and I really
have no idea why it exists or what happens if "force" is not given.

My current thinking:
1) should figure out what "force" really does, and more importantly:
what happens if "force" is not given
2) su-l, runuser-l, sudo-i should probably call pam_keyinit with
force
3) depending on 1), su, runuser, sudo pam files should either all
invoke pam_keyinit.so, or none of them should.

Chris