openssh vs pam

[Frank Cusack]

On June 25, 2005 11:38:46 PM +1000 Darren Tucker <dtucker at zip.com.au> wrote:
> Frank Cusack wrote:
>  > Darren (et al.),
>  > Thanks for taking so much time here!  I wish I had more time to
>  > devote to it.
>
> That's OK.

Thanks also for being so calm in the face of some level of bitterness.
Sorry it's taken me so long to respond.  I'm amazingly busy these days.

> [about sshd's PAM interface]
> [...]
>>> It's never going to be perfect. Given the SSHv1 and v2 protocol
>>> specs and PAM as it stands I don't think it's possible.
>>
>> Disagree. It is quite possible for ssh v2 to work properly with PAM.
>> I have it working. Sun has it working.
>
> I specified SSHv1 and SSHv2, but sticking to just SSHv2, could you please explain how you do the
> following within the existing SSHv2 protocol and PAM interfaces:
>
> a) Perform the "none" auth test specified by SSHv2 via PAM without causing either unnecessary
> delays or spurious failure messages from PAM in the logs.  Currently sshd doesn't try PAM for
> "none" if PermitEmptyPasswords=no but strictly speaking that's a hack.

Can't remember exactly how I solved this, if I even did, but I definitely
did patch some code around this problem.  I think I just implemented the
hack you're talking about.  I like Nico's/Sun's approach here.

> b) Perform vanilla "password" USERAUTH_REQUEST via PAM in a way that works for the general case.
>
> Now a) you can configure around, and I imagine your response to b) will be "use kbdint, that's
> what it's for!" :-)

That's right.  passwd auth does NOT work with PAM 100% and CANNOT.  That's why kbdint
is there.  kbdint does everything passwd auth does, there's no reason to use passwd
auth.

> My point is there are parts of the spec that you can't implement perfectly via PAM, given the
> current protocol and PAM implementations. It's not that OpenSSH can't improve (I've already said
> that it can).

Sure, if you're stuck with passwd auth.  I'm not concerned about that, I'm
concerned about the things that can be fixed that aren't.

> Originally I had another thing in the list, which I now think is possible but tricky, and wanted
> to know if you implemented it and if so, how:
>
> c) Handle the case where pam_acct_mgmt() wants to interact after a public-key authentication.

I never addressed this myself.

>
>>> 6) The multiple-messages part of the PAM conversation protocol (ie
>>> allowing more than one message per call to the conversation
>>> function) is more complex than necessary and this has been a source
>>> of bugs.
>>
>> A big no here.
> [...]
>> Multiple messages are required because a) authentication exchanges
>> are not limited to single request/reply type of messages, and b)
>> clients cannot derive any semantic meaning from server-generated
>> messages.
>
> It's not that there are multiple messages in the authentication exchange, but that there's
> multiple authentication messages *per API call*, in a format that can be silently gotten wrong in
> a way that's a security problem (and, historically, has been).

huh?  Multiple messages per API call is what I'm saying is an absolute
requirement.

> Exhibit A: LinuxPAM got it wrong and nobody noticed until it was to late to fix it.  It's still
> broken to this day.
>
> (For anyone following the thread that doesn't realise: the PAM spec (XSSO, pp 89) specifies that
> the message parameter passed to the conversation function is "a pointer to an array", but
> LinuxPAM treats it as an array of pointers.  These are equivalent for the case where there's
> exactly one message but will blow up horribly for more.)

That can't be right.  The message parameter has to be dealt with in
two places, the pam module and the application.  Since Linux-PAM is
just the pam stack and modules, they don't control the applications,
applications will therefore be broken with Linux-PAM in the face of
multiple prompts.  I find it hard to believe that all applications
that have a Linux port implement both behaviors.

Ok, I've just looked at Linux-PAM-0.77 (from FC3) and of the 30
modules, 11 have a conversation interaction.  Every single one of
those does treat it incorrectly, but also every single one of
those only sends a single prompt.  So the fact that it's coded
incorrectly doesn't matter.  Most notably, pam_userdb is really
bad (getting even more wrong than mixing up arrays/pointers)
but still it only passes 1 message to conv() so it works.

I'd like to hear more if you disagree.  Although let me say
upfront that I probably won't be able to get back to this again.
Certainly all my homebrew modules work perfectly under Linux-PAM
(except when using the crud known as pam_stack).

> Exhibit B: des at freebsd, who wrote one of the PAM implementations (OpenPAM) from scratch, got it
> wrong in the FreeBSD sshd PAM code:
> http://mail-index.netbsd.org/current-users/2003/10/02/0005.html
>
> So the authors of two of the three PAM implementations I'm aware of have got it wrong at one time
> or another, in at least two cases undetected long enough to make it to released code.
>
> (and I'm not trying to pick on either des or amorgan here, but with a history of misuse of the
> interface even by folks that know it well, you have to ask if maybe the interface is at fault
> here)

Lots of interfaces are difficult.  Something as tricky as a pam
module, however, is easy to get right if you do adequate testing.
I don't see it in XSSO but in the original pam spec (OSF RFC 86.0)
there is sample code that demonstrates pointer to array.  I don't
know how you can get it wrong when you have sample code to look at.

> A separate but related issue to the fact this complex interface is supplied via a callback.  It's
> the callback that's the primary problem in sshd's case, though.  Give me a reentrant equivalent
> to the conversation function and I can live with the rest.  It could probably even fit withing
> the existing API with a few new flags.

You keep saying reentrant.  You mean asynchronous.  I agree,
such an interface can probably be wedged in.  libpam would
just have to fake the conversation function.  I'd love to work
on it if I had cycles available.

>> This is a great example of both not understanding PAM and not wanting
>> to. One, you're wrong, two, you can't imagine that the PAM interface
>> might be the way it is for a reason, rather you insist that it's
>> broken and refuse to accommodate it.
>
> You seem to be confusing understanding it with having a high opinion of it.  Do you believe that
> PAM is so fundamentally clean, elegant and beautiful that if someone understood it they could not
> fail to like it?

Yes.  I like BSDAUTH better because the authentication runs
in a separate process, but PAM is nice as well.  Part of
understanding PAM is understanding how things were when it
was developed.  Not how things are now.  TELNET was king.
ssh1 was just becoming known.  I don't think SASL was
around yet.

It's not so great for current uses, but certainly it solved
a real problem in an extensible way, and was appropriate.
And therefore elegant.

Not sure what you have against callbacks.  Because of the
stack function of pam, it's easier for app writers to supply
a callback than to deal with multiple "callinto's".

I agree, this causes problems *for SSH* but it's not such
a terrible design *in general* and especially considering
the environment in which it was developed.

[...]
>> pam_authenticate():
>>  info_request:  0: [enter password], type prompt
>>  info_response: 0: 1234
>> pam_acct_mgmt(): PAM_NEW_AUTHTOK_REQD
>> pam_chauthtok():
>>  info_request:  0: [your password has expired], type message
>>                 1: [old password], type prompt
>>                 2: [new password], type prompt
>>                 3: [verify], type prompt
>>  info_response: ...
>>
[...]
>>
>> Now, previously, in one sense I did overstate the case when I said
>> "it's easy". The issue just described is a subtle one, and is
>> probably not even understood by many of the current PAM stack
>> implementers and maintainers. Even the authors of PAM don't describe
>> this in the PAM specification, and in fact they get a few things
>> wrong! (viz, they claim kerberos and smartcard support, which isn't
>> possible strictly within the PAM framework as specified.)
>
> The authors of the standard and some of the implementations don't understand the interface?  Does
> this not indicate that the interface is too complex and thus prone to misuse?

OK, I did get ahead of myself a bit, but what I really meant
was that for application writers the complexity of the pam
stack isn't an issue.  The API that applications use isn't
difficult.

I hate to do this, but I've spent the better part of an hour on
this and it's very late here (3:40AM).  There's still a lot more
to respond to, and some of it central to our discussion, but
I just can't spend more time on this.  I'll just cherry pick
an easy last point:

>> The Sun patches are readily available.
>
> Really?  Where?  If you're referring to OpenSolaris the when I looked, ssh was one of the
> components that is not part of the release.  (Nico: any particular reason for this, and is it
> expected to change?)

oops.  Sun had released source for a bunch of packages with 'S" suffixes,
eg SUNWbashS.  I thought openssh was among those.  Anyway, it looks like
you can get it now from opensolaris.org, in the add-on crypto tarball.

Thanks again for spending so much time in an area that really
is one of the weak points of ssh anyway.  Folks should be using
pubkey auth.  Sending your password to anyone is so 1990.

-frank