[Bug 2246] specify PAM service name, per authn-method service names

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2246

Kirill 'kkm' Katsnelson <kkm at pobox.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kkm at pobox.com

--- Comment #10 from Kirill 'kkm' Katsnelson <kkm at pobox.com> ---
Damien, another important thing to consider here is the interactive vs.
non-interactive nature of the session. When the used logs on
interactively, the pam_systemd session module is usually in the stack,
and this creates the whole shebang of the session for the user.
However, when the host is connected for port or stream forwarding or
the subsystem only (jump host, or an sftp connection), the interactive
session makes no sense.

On a jump proxy (thanks for implementing the ProxyJump shortcut, by the
way, my favorite addition ever!), I normally modify the distro-supplied
PAM configuration to bypass systemd user session mechanism.

Unfortunately, this is not as clear cut as i wished it were. Is, for
one, scp an interactive login or not? From the client's point of view,
it's not, but the server cannot tell (if I understand how the protocol
works); a command is just a command. The same goes for the
ProxyCommand, which the server sees as _just_ a command. Does it need
the full user environment, such as, e. g., active DBus session? The
server has no idea at the moment when the service is started.

One feeble attempt to, at the very least, _guess_ whenther an
interactive session is wanted is the PTY request by the client. Another
strong clue is, when the server is in forward-only mode ('MaxSessions
0'), then the session is clearly non-interactive. A request for a
subsystem with MaxSession=1 is also likely, but again, not necessarily
noninteractive. And then what to do with connection multiplexing: I
usually do not open an sftp session and then multiplex an interactive
shell, but people use complex tools like ssh in unimaginably complex
ways. All in all, this guesswork is messy and as far away from The
Right Thing as I could only think.

Maybe there should be an explicit interactive session request in the
protocol, like "client requests an { interactive | non-interactive }
logon session", with the current behavior (admin's discretion) as the
default? There are possible security implications from server
misconfiguration, naturally, but if anyone is using systemd session
mechanism as a security control, they are doing it wrong anyway.

Another possible way to approach this issue is akin to
AuthorizedKeysCommand: let a script to decide what pam service to use,
given all the interesting information about the request (the command,
auth method, the remote and local endpoints, etc.). This would also
cover the original idea of using the token substitution, where the
impetus for the change was, as I understand, is to decide on the PAM
service based on the auth method, which would also be made available in
the external command's environment.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.