openssh bugs - Jun 2014 - [Bug 2246] New: PAM enhancements for OpenSSH server

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

            Bug ID: 2246
           Summary: PAM enhancements for OpenSSH server
           Product: Portable OpenSSH
           Version: 6.6p1
          Hardware: Sparc
                OS: Solaris
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: PAM support
          Assignee: unassigned-bugs at mindrot.org
          Reporter: huieying.lee at oracle.com

Created attachment 2441
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2441&action=edit
pam_enhancements for OpenSSH server

We have implemented the following PAM enhancements for Solaris and we
would like to contribute back our implementations for these
enhancements:

1) Each SSHv2 userauth method has its own PAM service name so that PAM
can be used to control what userauth methods are allowed.  This is for
protocol 2 only. 

     -----------------------------------------------
     | SSHv2 Userauth       | PAM Service Name     |
     -----------------------------------------------
     | none                 | sshd-none            |
     -----------------------------------------------
     | password             | sshd-password        |
     -----------------------------------------------
     | keyboard-interactive | sshd-kbdint          |
     -----------------------------------------------
     | pubkey               | sshd-pubkey          |
     -----------------------------------------------
     | hostbased            | sshd-hostbased       |
     -----------------------------------------------
     | gssapi-with-mic      | sshd-gssapi          |
     -----------------------------------------------


2) The PAMServiceName and PAMServicePrefix options in the server's
sshd_config configuration.

     PAMServiceName
          Specifies the PAM service name for the PAM session. The
          PAMServiceName  and  PAMServicePrefix options are mutu-
          ally exclusive and if both set, sshd does not start. If
          this option is set the service name is the same for all
          user authentication methods. The option has no  default
          value. See PAMServicePrefix for more information.

     PAMServicePrefix
          Specifies the PAM service name prefix for service names
          used  for  individual  user authentication methods. The
          default is sshd. The PAMServiceName and  PAMServicePre-
          fix  options  are  mutually  exclusive and if both set,
          sshd does not start.

          For example, if this option is  set  to  admincli,  the
          service  name  for the keyboard-interactive authentica-
          tion method is admincli-kbdint instead of  the  default
          sshd-kbdint.


Note that we understand that there is a bug in OpenSSH's bugzilla for
the PAMServiceName option already (bugid = 2102).  The reason that it
is still listed here is to show the relationship between it and the
PAMServicePrefix option.

Attached is our implementation patch, which was applied to
OpenSSH6.5p1.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

huieying.lee at oracle.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P5                          |P3

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2441|application/octet-stream    |text/plain
          mime type|                            |
   Attachment #2441|0                           |1
           is patch|                            |
                 CC|                            |dtucker at zip.com.au

-- 
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.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
I think it would be better to support a couple of %-escapes in
PAMServiceName. E.g.

PAMServiceName sshd-%m

where %m is replaced with the authentication method in use. Some others
for port number and interface address might make sense too.

Also, I don't think the proposed patch is correct - there is state in
auth-pam.c that should be stored separately per service name.

E.g. a PAM stack for password auth might set sshpam_account_status.
Later, a different authentication method might be tried resulting in a
different PAM stack being executed, but this cached value will still be
preferentially used. This could allow access inappropriately (or
vice-versa)

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

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

--- Comment #2 from huieying.lee at oracle.com ---
Thank you for the evaluation and suggestion.  I would like to confirm
with you for the following three items:

1) PAMServiceName sshd-%m

I interpreted your suggestion for this option as following:

The value of the PAMServiceName option can be specified as
"service_name" or "service_name-%m"

a) PAMServiceName service_name

   Only one PAM service for all user authentications with
"service_name" as the PAM service name.

b) PAMServiceName service_name-%m

   An administrator can use this option for SSHv2, so that each
userauth type has it own PAM service name.  For example, if
"PAMServiceName sshd-%m" is specified, then the pam service name will
be expanded to sshd-password, ssh-kbdint, sshd-pubkey, sshd-hostbased
and sshd-gssapi respectively for the password, keyboard-interactive,
pubkey, hostbased and gssapi-with-mic authauth methods.

   This applies to SSH protocol 2 only.

c) If the "PAMServiceName" option is not specified in the sshd_config
file, then it defaults to "PAMServiceName sshd", which means that
there
is only one PAM service and the server name is "sshd".  Note that this
matches the current OpenSSH default behavior.

Is my interpretation correct ?

2) The PAM state problem in the proposed patch 

You are right that there may be some state problems in the case of
"each SSHv2 userauth method has its own PAM service name" situation. 

Although the PAM service will be invoked many times in this case, they
are invoked sequentially and there will be always only one pam_handle
at any moment. Therefore, we can resolve this problem by cleaning up
PAM stuff, calling pam_end(), before invoking a new PAM service.  And
the PAM state can be stored in the those static variables in
auth-pam.c.
for examples, 

static pam_handle_t *sshpam_handle = NULL;
static int sshpam_err = 0;
static int sshpam_authenticated = 0;
static int sshpam_account_status = -1;
static char **sshpam_env = NULL;

3) The pam_acct_mgmt problem in the patch

While checking into the state problem,  I also found another problem in
the patch.  The pam_acct_mgmt() should be called also for each userauth
method if each userauth method has its own PAM service.  I will fix
this problem and submit another patch later.

Note that pam_setcred() and pam_open_session() do not need to be called
for each userauth method.  They can be called after all the userauth
methods are processed, as long as there is a valid pam_handle.

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

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

--- Comment #3 from huieying.lee at oracle.com ---
Created attachment 2504
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2504&action=edit
pamservicename_enhancement.patch

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

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

--- Comment #4 from huieying.lee at oracle.com ---
I have completed the implementation of the new "PAMServiceName" option
that you suggested.  I also fixed the PAM state problem that Damier
brought up in July and fixed the pam_acct_mgmt() problem I discovered
myself.

Attached is the new PAMServiceName implementation patch.  Could you
please review it and let me know if there are any problems ?  We really
want to keep our OpenSSH deliverables as close to the upstream as
possible; if possible, could you please let us know at your earliest
convenience as we are trying to complete our current release which we
strive to be in-sync with the future OpenSSH release. 

For your reference, this new PAMServiceName option is documented in the
sshd_config man page as below:

-----------------------------------------------------------------------
PAMServiceName

      Specifies the    PAM service name for the PAM session. The valid 
          arguments are "service_name" or "service_name-%m".

          1) PAMServiceName service_name

             Specifies the PAM service for all user authentications,  
             where "service_name" is the PAM service name.  For   
             example, if "PAMServiceName mysshd" is specified, then
             "mysshd" is the PAM service name for all user
             authentications.

          2) PAMServiceName service_name-%m

             This option only applies to SSH protocol 2. 

             With "-%m", each user authentication type has its own PAM
             service name. 

             For example, if "PAMServiceName sshd-%m" is specified,
             then the pam service name is expanded to sshd-pubkey for
             public key authentication, to sshd-kbdint for
             keyboard- interactive authentication, and so on.

               SSHv2 Userauth         Expanded PAMServiceName
               --------------         -----------------------
               none                   sshd-none
               password               sshd-password
               keyboard-interactive   sshd-kbdint
               publickey              sshd-pubkey
               hostbased              sshd-hostbased
               gssapi-with-mic        sshd-gssapi

             If "PAMServiceName mysshd-%m" is specified, then the PAM
             service name is expanded to mysshd-pubkey for public key
             authentication, to mysshd-kbdint for keyboard-interactive
             authentication, and so on.

               SSHv2 Userauth         Expanded PAMServiceName
               --------------         -----------------------
               none                   mysshd-none
               password               mysshd-password
               keyboard-interactive   mysshd-kbdint
               publickey              mysshd-pubkey
               hostbased              mysshd-hostbased
               gssapi-with-mic        mysshd-gssapi


          3) If "PAMServiceName service_name" or 
         "PAMServiceName service_name-%m" is not specified, then 
             "sshd" is the PAM service name for all user 
             authentications.

             Note that this matches well with the current OpenSSH 
             default behavior.
-----------------------------------------------------------------------

Thanks,
Huie-Ying Lee

-- 
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.

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

--- Comment #5 from huieying.lee at oracle.com ---
We need to make decision based on your assessment soon.  Any comments ?

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

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

--- Comment #6 from huieying.lee at oracle.com ---
Created attachment 2588
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2588&action=edit
PAMServiceName/PAMServicePrefix enhancements (with bugfixes)

-- 
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.

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

--- Comment #7 from huieying.lee at oracle.com ---
We thought that the single "PAMServiceName service-%m" is a better
design (suggested by Damien Miller on 2014-07-03) over our
PAMServiceName and PAMServicePrefix enhancements. However, I have not
received any response, even though I have asked for feedback on my
submitted implementation many times since August of last year. 

We will choose the "PAMServiceName service-%m" design, if OpenSSH.org
will confirm that you will incorporate this design (an implemenation of
which I provided on 2014-11-06) in a future OpenSSH release. 

Failing that, to prevent an incompatibility issue during upgrade, we
will
use our original two option design.  The PAM state and PAM account bugs
in the original patch file (submitted on 2014-06-19) have been fixed. A
new patch file for the two-option PAM enhancement was attached in this
bug a few minutes ago.

Please re-evaluate these enhancements and let us know your decision.

Thanks,
Huie-Ying Lee

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

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kenneth.schmidt at pnnl.gov

--- Comment #8 from Damien Miller <djm at mindrot.org> ---
*** Bug 2102 has been marked as a duplicate of this bug. ***

-- 
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.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|PAM enhancements for        |specify PAM service name,
                   |OpenSSH server              |per authn-method service
                   |                            |names

-- 
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.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2504|0                           |1
        is obsolete|                            |

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

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2441|0                           |1
        is obsolete|                            |

-- 
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.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |corvuscorax at cybertrench.com

--- Comment #9 from Damien Miller <djm at mindrot.org> ---
*** Bug 2980 has been marked as a duplicate of this bug. ***

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

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.