PAM bashing (was Re: kerberos support in ssh/lsh)

[nisse@lysator.liu.se (Niels Möller)]

GOMBAS Gabor <gombasg@inf.elte.hu> writes:

> Let me argue that.

I'm afraid we're drifting off-topic, but ok, let's argue some. 

> The interface of PAM is not brain-damaged at all. It is designed to
> provide _interactive_ _password-based_ authentication services.

Quoting the first paragraph of the PAM docs I have here (more
precisely UNIFIED LOGIN WITH PLUGGABLE AUTHENTICATION MODULES (PAM),
V. Samar, R. Schemers, "/usr/doc/pam-0.66/rfc86.0.txt" on a typical
linux system):

: PAM's ability to _stack_ authentication modules can be used to
: integrate `login' with different authentication mechanisms such as
: RSA, DCE, and Kerberos, and thus unify login mechanisms. The PAM
: framework can also provide easy integration of smart cards into the
: system.

My interpretation is that PAM was designed to handle a lot more than
interactive password based authentication, and failed miserably in
that respect. 

> It's quite true however that the SSH protocol does not support
> interactive authentication at all (at least the 1.x versions do not; I
> haven't looked at the 2.0 protocol closely yet).

There's a document draft-ietf-secsh-auth-kbdinteract-00.txt that
defines that, mostly aimed for supporting things like securid tokens.
I haven't looked closely at it.

> You write at the above URL that the PAM messages are not abstracted.
> Quite the contrary, it is a completely abstract interface providing
> a method for an authentication module to communicate with the user.

You are saying that PAM provides an abstraction for talking to the
user. That's true. I'm saying that PAM provides no abstraction at all
for the *messages* that are sent. The messages are supposed to be
opaque to all software on their way to the user; i.e PAM refuses to
tell the involved applications anything about what the messages means.
That sucks big time for applications like an sshd daemon that needs to
know that. I suppose there are work-arounds, but they will be ugly,
because PAM makes the assumption that nobody but PAM ever needs to
know any of those details.

The communication that needs to take place between an sshd server and
a client requires more knowledge about what the authentication system
(e.g. PAM) is asking for. An sshd client typically has a few potential
means to gain access; it can ask the user for a password (unless
running in some kind of quiet batch mode), it may have a few user keys
that it can ask the user to unlock, there may be some smart cards or
tokens attached to the environment or to the user. It doesn't make
sense ask the user for all passwords to all keys and tokens and try
them blindly. Instead, the server gives the client a list of the
userauth methods that are appropriate, and the client chooses one at a
time and cooperates with the user to try to get access.

That won't work at all with the PAM abstraction, because there's no
clean way to even ask PAM whether or not password authentication is
allowed. 

> However, limited PAM support (using pam_authenticate only, no password
> change support) is quite easy and is enough for the majority of users. And
> even the password change can be hacked into SSH (not nice at all, but
> works).

Doing pam_authenticate only seems quite pointless to me.

I don't want to use PAM in lshd, for those reasons:

1. PAM is not a tool that fits the needs of an ssh daemon. (Wrong
   level of abstraction, wrong assumptions, etc. And then the
   blocking-ness issue on top of that).

2. I have to support non-PAM methods anyway, as many systems don't
   have PAM.

3. The non-PAM methods are supported on practically all PAM-systems as
   well, because many applications are not PAM-aware.

4. PAM adds a lot of complexity for quite a small gain.

5. There have been too many bugs and security holes in various parts of
   PAM (likely because of 4).

I wouldn't recommend anyone to use PAM for network authentication.

If you disagree, you probably think that applications and network
protocols should adapt to PAM's view of the world. That the ssh
protocol is broken because it doesn't fit well with PAM. That may make
sense sometimes, but not for an application implementing a given
protocol like ssh...

I'd prefer that os:s, libraries, toolkits and other application
building blocks not try to enforce their view of the world, but
instead be flexible enough to be able to bend to the needs of all
reasonable applications.

/Niels