[Bug 423] Workaround for pw change in privsep mode (3.5.p1)

[Michael Steffens]

Darren Tucker wrote in
    http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=103658633821391
 > This raises another possibility for changing passwords.
 >
 > As I see it the options now are:
 >
 > 1) Platform specific functions
 > Pro: RFC compliant
 > Con: extra code that runs as root

That's what I would consider the clean solution. And for
PAM it would even be only moderately platform specific.
But I found it complicated, thus wrote ssh-chauthtok-helper
and called it a workaround.

 >
 > 2) Spawn /bin/passwd in session
 > Pro: Simple, portable
 > Con: Not RFC compliant, possible timing attacks against proto 2?

Agreed for non-PAM, but with PAM there arises an issue. (See below)
One could consider ssh-chauthtok-helper the PAM-variant of this
approach.

 > 3) Platform-specific setuid helpers
 > Pro: Consistent v1 & v2 interface, delegate policy to user-written
 > helpers, RFC compliant.
 > Con: Potential attacks against setuid programs, repeated code (eg
 > command line parsing).

I think only two of them are required. The system native passwd
program is already the suid helper for non-PAM, and for PAM
one sshd specific helper can do the job.
 >
 > 4) Spawn /bin/passwd in tty (ala "expect")
 > Pro: portable? RFC compliant.
 > Con: lots of code, hard to get right, potentially flakey
 >
 > I know Markus doesn't like 1) and says that the only portable thing to
 > do is 2). Isn't this similar the the case for UseLogin? After all the
 > only portable way to do user authentication is /bin/login, but UseLogin
 > defaults to no and is considered depreciated, right?
 >
 > I'm still in favour of 1). The platform-specific change functions that
 > I've done so far[0] are ~40 lines (AIX) and ~100 lines (/etc/shadow).
 > The shadow function handles 3 platforms (Solaris, Redhat, UnixWare).

This is only true for Solaris and Redhat (don't know about UnixWare)
if sshd is not configured to use PAM for authentication! Otherwise it's
calling for mismatches.

In the view of PAM "passwd" and "sshd" are different services. The PAM
modules configured for them do not need to be the same, and they do
not need to be configured with the same parameters.

A user could authenticate using one (set of) module(s), but then
change password(s) with a different one, using passwd.

 > The
 > rest of the patches are required to check whether or not a password is
 > expired regardless of which method is used to change it.
 >
 > Regarding 3): if a consistent enough interface was specified you could
 > use the same setuid helper for PASSWD_CHANGEREQ during proto 2
 > authentication as well as proto 1 sessions.
 >
 > Also, can someone who knows PAM please tell me if it's feasible to
 > implement a function like:
 > pam_change_password(char *user, char *oldpass, char *newpass)?
 > Or is some odd PAM module likely to render that impossible?

It doesn't even need to be that odd :)
Two things do make it impossible in general:

  - PAM allows to configure multiple modules (and passwords) to be
    required for a specific service. The pam_chauthtok() function
    will check them all, according to configuration. But how should
    that work with only these three arguments for pam_change_password()
    being given?

  - PAM is being given a conversation callback function on pam_start(),
    used for user interaction. How exactly dialogs are being performed
    is up to the modules then. As an example for an "odd" pw change
    dialog you may look at the HP-UX default when running in trusted mode:

      Changing password for dummy
      Old password:
      Last successful password change for dummy: NEVER
      Last unsuccessful password change for dummy: Wed Oct 23 08:35:45 2002

      Do you want (choose one letter only):
              pronounceable passwords generated for you (g)
              a string of letters generated (l) ?
              to pick your passwords (p) ?

      Enter choice here: g

      Generating random pronounceable password for dummy
      The password, along with a hyphenated version, is shown.
      Hit <RETURN> or <ENTER> until you like the choice.
      When you have chosen the password you want, type it in.
      Note: type your interrupt character or `quit' to abort at any time.

      Password: kretavikuj  Hyphenation: kret-av-ik-uj
      Enter password:
      Password: ruhizacnat  Hyphenation: ru-hiz-ac-nat
      Enter password:
      Re-enter new password:
      Passwd successfully changed

    I would say it's impossible to encapsulate such dialogs using
    a function like you are suggesting, unless you restrict
    to option (p), and prepare for being presented the choice,
    of course.

    This is also the reason why I found it too complicated to
    implement the clean solution 1) for the moment. It would
    require to tunnel the entire conversation between session
    daemon and monitor, rather than just doing a request/response
    between these.

Cheers!
Michael