Password expiry patch plans

[Michael Steffens]

Ben Lindstrom wrote:
> Two reasons.
> 
> 1. It is yet another setuid binary (well maybe not in OpenBSD's case), but
> I'm not really not sure I want to even go near the topic with Theo/Markus.

It is a workaround. As soon as there is a possibility to have the
monitor talk to PAM and the unpriv child talk to the user for PAM
conversation, it would be obsolete.

> 
> 2. Anytime you write such things you MUST ensure all your p's and q's are
> right.  That there is *NO* way for someone to abuse it from user space.
> Which brings me back to #1.

The ways I tried to ensure this were:

  - Make it small and simple

  - Don't allow anything a userspace caller couldn't also do with /bin/passwd,
    if it were the same PAM stack.

  - Don't use user (command line) data which can't be verified. This was
    the reason to exclude PAM_RUSER and PAM_RHOST, which I had in an
    intermediate version. Requesting entities are not even the local
    ones, they are just unknown and left undefined. It's up to the modules
    to reject a change if they require these. This would be the point
    where the workaround's capabilities are exhausted.

    The only user supplied data preceding the dialog is the user name, which
    is required and used for redundancy (checked against real UID).

  - Restrict functionaly to base purpose, i.e. do only allow change
    of expired authentication tokens. Change of non-expired ones
    is rejected (and unnecessary for sshd's use, as it won't call it then).

  - Don't spawn any further children (despite what PAM modules might spawn
    themself, and would also do when called from inside sshd). Exclude
    ssh-askpass from conversation.


> 
> I agree it would be nice to this password change all through a helper
> program.  It would allow local admins to implement the level of strictness
> based on their needs (same with how we do entropy collection now), but
> again it comes back to the ability to abuse a setuid binary.

This is not what I had in mind. A general password change helper
would be considerably larger and much harder to review.

> 
> I don't want to be the next person to introduce the next misfeature into
> OpenSSH that allows the local machine to be comprised.  And skimming
> through your example code does not make me want to rush out and implement
> it.

I'm aware it's not perfect. But what do you mean specifically?