PAM kbd-int with privsep

[Darren J Moffat]

Damien Miller wrote:
> 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.

Using a different handle for auth, acct and session is a major issue for 
Solaris since there are private pam data items set in our pam_unix* 
module(s) by auth that are later retrieved by account and by account to 
be later retrieved by session and chauthtok. For this to work it 
requires the same pam handle to be used in all calls.  Not doing this 
isn't really using PAM as intended.

I understand this is difficult and I'm not bashing your current attempt, 
just pointing out that it is important.

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

That is how I had thought about doing it, I'm not sure about any 
priveilege escalation though since the calls to PAM must run with 
privelge anyway and the modules must be trusted.

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

These are Linux extensions to the framework.  The people who look after 
the Linux-PAM have made significant incompatible changes to the 
framework from the original RFC (which was never ratified by Open Group).

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

Agreed, last time Sun attempted to work with the Linux-PAM people on 
getting back in sync some minor progress was made but nothing concrete.

Open Group has officially released control of PAM back to its original 
inventors (Sun).  A new working group on PAM does need to be formed
since Linux and the original PAM have diverged too far.

--
Darren J Moffat