PAM kbd-int with privsep

[Damien Miller]

On Wed, 2002-06-26 at 02:39, Nalin Dahyabhai wrote:

> > The patch has a limitation: it does not handle multiple prompts - I have
> > no idea how common these are in real-life. Furthermore it is not well
> > tested at all (despite my many requests on openssh-unix-dev@).
>
> It looks like this limitation exists because the authentication via PAM
> is actually performed in a child of the privileged process, and the PAM
> handle is lost after successful authentication when this child exits.

The existing code could be modified to handle multiple prompts with some
more work, I just need to grok the kbd-int stuff a bit better.
 
> Once the PAM-encapsulating child exits, you don't have a context to
> perform account or session management with, so the ability to perform
> PAM session management is just lost.  Because PAM data items can point
> to dynamically-allocated memory, I don't see a clean way to transfer
> the context data to the parent.

We still do the account and session management, just with a different
PAM handle. Any state accumulated in the auth modules will be lost.
Ideally we would do both auth and acct in the PAM helper child, that way
we could handle password changing interactively.

> It might be fixable by modifying it to have the parent do the PAM work,
> but it'd require an approach similar the existing kbdint code, and I
> don't know how it would work in the context of a monitoring setup.

It is conceivable that we could hook into the shared memory malloc
routines to make the PAM context available to parent and child.
Unfortunately doing so may expose us to issues where the child attempts
privilege escalation by deliberately corrupting its PAM context.

> It might also be resolved (at least for Linux-PAM 0.65 and later and
> derivatives, I haven't a clue about other implementations) by using
> the PAM_CONV_AGAIN/PAM_INCOMPLETE framework and letting the privileged
> process drive the conversation, but the framework is not well supported
> by most of the modules I've spot-checked.  (That's fixable, though.)

Am I correct in believing that this framework isn't in the original PAM
RFC? If so, that doesn't help us for Solaris, HP/UX and other non-Linux
PAM-supported platforms.

This sort of framework is desperately needed though - PAM's design is
really showing its age and is not at all suited to async operation. It
would be excellent for everyone if the PAM spec could be reexamined with
these issues in mind (have a look at BSD auth[1] for inspiration). IMO
Redhat and Sun are in an excellent position to lead this process.

I hope this opportunity is not wasted.

-d

[1] 
http://www.openbsd.org/cgi-bin/man.cgi?query=authenticate&apropos=0&sektion=3&manpath=OpenBSD+Current&arch=i386&format=html
http://www.openbsd.org/cgi-bin/man.cgi?query=bsd_auth&sektion=3&arch=i386&apropos=0&manpath=OpenBSD+Current