Bug#739676: systemd-user PAM config breaks some libpam-* modules

[Christian Kastner]

Control: severity -1 serious

On Sun, 28 Dec 2014 18:29:57 +0100 Christian Kastner <debian at kvr.at> wrote:
> > The question is why the PAM stack is processed twice. Perhaps there is
> > some way to inhibit the second invocation, although I am not familiar
> > enough with systemd/logind to know what to change.
> 
> Thanks to grawity's help on IRC, who indicated that this second PAM
> session should be opened in the backround, similar to cron, I noticed
> that the PAM configuration for systemd-user @includes common-session,
> whereas cron's configuration @included common-session-noninteractive.
> 
> Using common-session causes the breakage in libpam-mount quoted above,
> and I assume in other libpam-* modules as well (see eg #572292 when this
> was changed in cron).
> 
> Changing systemd-user's PAM config to use common-session-noninteractive
> resolves the above issue (and actually another, yet unreported, one in
> libpam-mount).

I've raised the severity of this bug (more on that far below), as
quoting the original reporter:

On Fri, 21 Feb 2014 03:31:06 -0500 Jeremy Salwen
<jeremysalwen at gmail.com> wrote:
>> [...] it would properly mount my home directory, but failed to 
>> unmount it when I logged out. This is a security issue, as it 
>> leaves encrypted drives vulnerable.

It defeats the purpose of pam_mount when mounted devices are not
unmounted at logoff, and in the case of encrypted devices, this can
indeed be a security issue.

I've now run a few tests with other libpam-* packages, namely packages
which also use PAM session management (most libpam-* packages are just
for auth), and which were simple to test.

  * libpam-ck-connector: just prints an error:

        "cannot determine display-device"

  * libpam-script: Scripts are executed twice. Depending on the script,
    this could be a major issue

  * libpam-ssh: Apparently aborts the second session due to lack of a
    controlling tty

Some other modules which use PAM session management, but which I haven't
tested, are libpam-krb5, libpam-ldap, libpam-pgsql. I'm sure there are
many more.

The eventual severity of this bug is of course ultimately at the
discretion of the maintainers, but I hope the above is convincing enough
to keep it at serious. This would make the bug RC, but the second patch
I submitted to this bug [1] should provide a solution to the above
issues without (TTBOMK) introducing any new side effects to whatever
systemd-user does.

If this second PAM session via systemd-user is indeed intended to be
merely a background thing, them common-session-noninteractive should be
the way to go anyway. But I'm not familiar enough with systemd to make
that call.

Regards,
Christian

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=739676#28