openssh unix dev - Nov 2004 - openssh-3.7p1+ and PAM on OS X

Hello list,

Bug 688 is causing me a massive headache on OS X.

The fact that each PAM authentication takes place in a separate process 
means the PAM context data isn't shared and therefore prevents the 
passing of data between modules. (pam_set_data, and pam_get_data)

Compiling with pthreads isn't really an option because of the added 
security risk and the fact that some of the PAM modules are not thread 
safe and would be troublesome to make thread safe.

Storing the data in the environment really isn't an option, as it is 
sensitive.

Is there another solution that you could suggest?

How do you plan to fix 688?
does the fix have an ETA?

Cheers,
-Nick

Also, PAM support in 3.9p1 is completely broken on OS X. (I'm still 
investigating)

http://bugzilla.mindrot.org/show_bug.cgi?id=688

Nick Lane-Smith wrote:
> Bug 688 is causing me a massive headache on OS X.
> 
> The fact that each PAM authentication takes place in a separate process 
> means the PAM context data isn't shared and therefore prevents the 
> passing of data between modules. (pam_set_data, and pam_get_data)
> 
> Compiling with pthreads isn't really an option because of the added 
> security risk and the fact that some of the PAM modules are not thread 
> safe and would be troublesome to make thread safe.
> 
> Storing the data in the environment really isn't an option, as it is 
> sensitive.
I thought the PAM environment (pam_putenv, pam_setenv) is a separate 
namespace to the regular environment space and not visible to other 
users.  (Or are you worried about the PAM application or other PAM 
modules getting their hands on this data?)
> Is there another solution that you could suggest?
Is the PAM password authentication (via a "blind" conversation
function)
in 3.9p1 usable for you?  It doesn't fork, and it would be relatively 
easy to backport if necessary.  It's no good for real challenge-response 
though.
> How do you plan to fix 688?
Possibly, if there's some cure that isn't worse than the disease.  So 
far, one hasn't been obvious :-)
> does the fix have an ETA?
Not right now.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

Nick Lane-Smith wrote:
> Bug 688 is causing me a massive headache on OS X.
[..]
> How do you plan to fix 688?
Sorry, I missed the "How" in my first reply.

So far there appears to be two potential solutions, neither of which are 
particularly palatable:

1) Invert the parent-child relationship in the existing code: ie have 
the parent make the PAM calls and the child talk to the user/privsep 
slave.  (Ironically, this may be easier to implement with privsep than 
without it since key and compression state is less of an issue).

See http://marc.theaimsgroup.com/?l=secure-shell&m=108231421231223

2) Implement the PAM conversation as a coroutine.  Clever, but 
potentially unportable, a maintenance hassle and a debugging nightmare.

See http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.