Bug#726661: login fails with pam_loginuid(sshd:session): set_loginuid failed

[Simon McVittie <smcv@debian.org>]

Control: tags 726661 + moreinfo

On Thu, 13 Nov 2014 at 09:19:42 +0000, Simon McVittie wrote:
> Anyone else, please reply to #726661 if discussing pam_loginuid or
> the new clone (bug number to be determined) if discussing PermitRootLogin.

Here is the part of that bug specifically about pam_loginuid. I believe
this regressed when https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=677440
was fixed, adding pam_loginuid for the benefit of (at the time) ConsoleKit;
it is also used by auditd and systemd-logind.

I cannot reproduce this bug on a (somewhat outdated) jessie system with
sysvinit. I would like some more information from the people who are
affected by it:

* Are you using a non-Debian kernel?
* Does your kernel have AUDIT_LOGINUID_IMMUTABLE set in its configuration?
* What init system are you using? (sysvinit? systemd? Upstart? something else?)

Further discussion of possible causes, workarounds, etc. below.

----

I've added a bunch of somewhat relevant people to Cc: everyone who
reported seeing this bug or similar, Laurent and Michael because they
were involved in #677440 and seem to know about loginuid/audit in general,
and the PAM maintainers.

Summarizing for those who weren't previously in Cc, I think
the steps to get this bug are something like this:

* Have a non-Debian kernel configuration (?)
* Run sysvinit (*not* systemd or Upstart) as pid 1
* pid 1 and other system services initially have loginuid -1, which
  means "undefined, not part of a login"
* Be in a root shell that has been given a loginuid other than -1, either:
  - log in as root with a version of login, openssh-server, etc.
    that uses pam_loginuid; your loginuid will be 0
  - log in as an ordinary user (uid 1234, say) with a version of login,
    openssh-server, etc. that uses pam_loginuid, and use su or sudo to get
    the necessary root privileges to restart openssh-server; your loginuid
    will be 1234
* Restart openssh-server, either manually or as a side-effect of an upgrade
* Start a new parallel login via ssh, either as uid 0, 1234 or something else
* cat /proc/self/loginuid

Desired result (which is what I get):

* New parallel login succeeds
* In the new parallel login, /proc/self/loginuid equals $(id -u)

What seems to be happening to the people affected by this bug, but I
cannot reproduce it:

* The restarted openssh-server has the same loginuid as the shell from
  which you started it
* Transitions from loginuid == -1 to loginuid != -1 are not allowed [1]
* pam_loginuid fails with: pam_loginuid(sshd:session): set_loginuid failed

[1] surprises me, because this is conditional on a kernel option,
AUDIT_LOGINUID_IMMUTABLE, which is designed for systemd and similar
systems and doesn't seem to be set in Debian kernels according to
/boot/config*... see
<https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=633b454>.

Possible workarounds include:

* Remove pam_loginuid.so from the ssh configuration (confirmed to work,
  but it would reopen #677440 and doesn't seem a great idea distro-wide)
* Use a modern init system that starts system services via IPC to pid 1,
  i.e. systemd or Upstart
  - The restarted openssh-server has loginuid -1
  - The transition from -1 to 4321 succeeds
  - Everything's fine
* Use a Debian kernel without AUDIT_LOGINUID_IMMUTABLE (?)
* Drop pam_loginuid.so from required to optional in the ssh configuration (?)

It's a pity we can't enable pam_loginuid.so if and only if init is
modern (systemd or Upstart). Perhaps patching it would be another option?

As far as I can see, other services that use pam_loginuid would typically
have the same bug, but there are mitigations:

* getty/login are started by "IPC" to init (edit inittab, send signal)
  even under sysvinit, so they are unaffected
* Display managers (gdm, lightdm etc.) are not typically restarted
  automatically on upgrades because that would disrupt current X sessions,
  so they are unaffected unless the user restarts them manually without
  rebooting

If my assumptions about the cause are correct, then I can't see any way
to get the desired result in openssh-server when run under sysvinit.
Can someone else?

The best I can come up with so far is to to change from the current

    session required pam_loginuid.so

to

    session optional pam_loginuid.so

That would mean that login to the restarted openssh-server worked, but
its sessions had the wrong loginuid until the machine was rebooted.

Regards,
    S