[Bug 2548] Make pam_set_data/pam_get_data work with OpenSSH

bugzilla-daemon at bugzilla.mindrot.org bugzilla-daemon at bugzilla.mindrot.org
Sat Mar 5 03:00:26 AEDT 2016


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

--- Comment #1 from Tomas Kuthan <tomas.kuthan at oracle.com> ---
Created attachment 2796
  --> https://bugzilla.mindrot.org/attachment.cgi?id=2796&action=edit
Switch roles of monitor and auxiliar PAM process in PAM authentication.

The proposed patch fixes this by switching the roles of the monitor
and the auxiliary process when doing PAM authentication. In the new
code the monitor will be the one calling pam_authenticate and
pam_acct_mgmt (eventually blocking and calling callbacks), whereas the
other process (callback child) will be sending messages to the client
(either directly or through privsep child).

The resulting code flow looks like this:

(monitor)
   |
  fork --------------------------(privsep child)
   |                                    |
pam_start                               |
   |                                    |
  fork ------- (callback child)         |
   |                  |                 |
pam_authenticate      |                 |
   |                  |                 |
pam_acct_mgmt         |   <--msgs-->    |
   |                  |                 |
pam_chauthtok         |                 |
   |                  |                 |
   |                  X                 |
   |                                    |
   |                                    X
   |
pam_setcred
   |
pam_open_session
   |
  fork ------ (authenticated child)
   |                 |
   |              setreuid(100)
   |                 |
   |                fork ------- (future shell)
   |                 |                  |
   |                 |              exec(bash)
   |                 |                  |
   |                 |                  X
   |                 |
   |                 X
   |
pam_close_session
   |
pam_setcred
   |
pam_end
   |
   X

When the monitor is done calling PAM functions, it sends the callback
child a message relieving it from the duties. In response, the
callback child sends back any state information required and exits.
After that, the monitor resumes communication with the client.


When privilege separation is off, passing state from the callback
child back to the monitor is more tricky. The callback child has been
communicating directly with the ssh client for PAM prompts and
responses. When the monitor tries the resume the communication with
the client, the packet state has already diverged. The child has sent
several messages in between, and the client is expecting different
sequence number, different state of crypto counters and so on. As a
result, the child hangs up upon the first packet from the monitor
after the exit of the callback child.

To solve that, in the no privsep case, the callback child serializes
the packet state before it exits, sends it over to the monitor, which
restores the packet state. Now all the internal state matches and the
ssh client does not hang up anymore.


There is one corner case, where this does not work. When privilege
separation has been turned off (not recommended, on by default) and
compression has been set to 'zlib' (not recommended,
'zlib at openssh.com' by default), passing the packet state from the
callback child back to the monitor fails with a compression state
error.

In that case, the current patch prints an error message and sets
compression from 'yes' to 'delayed'.

Making it work even with 'early' compression is possible, but would
require keeping compression state in memory shared between the monitor
and the callback child. I believe supporting this undesired
configuration is not worth the damage it would do to the code layers
abstraction and the risks.


The proposed patch also removes the code for
UNSUPPORTED_POSIX_THREADS_HACK.  Now that all PAM calls take place in
a single process space, there is no need for thread support. As a nit,
substring 'thread' has been removed from symbol names too.

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


More information about the openssh-bugs mailing list