Date: Wed, 11 Nov 1998 20:32:42 -0800 (PST) From: John Polstra <jdp@polstra.com> To: Mike Smith <mike@smith.net.au> Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, Peter Wemm <peter@netplex.com.au>, "Jordan K. Hubbard" <jkh@zippy.cdrom.com> Subject: Re: cvs commit: src/usr.bin/login Makefile login.c Message-ID: <XFMail.981111203242.jdp@polstra.com> In-Reply-To: <199811112212.OAA05554@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11-Nov-98 Mike Smith wrote:
>>
>> Since you were doing all this for a client, I'm sure you also looked
>> at all the security issues and points of vulnerability before adding
>> PAM support - could you perhaps say a few words about this? I only
>> ask this specific pointed question because I have it on good authority
>> that the Red Hat folks didn't do this initially and suffered a large
>> number of security incidents traced to PAM in Red Hat 4.1 until they
>> finally got things sorted out. I don't know if it was a problem of
>> their implementation or design (I suspect the former), but it does at
>> least raise the reasonable question of security for us.
>
> The PAM-related incidents that I'm familiar with fall into a couple of
> categories:
>
> 1) Failings in the PAM architecture.
> 2) Buggy modules.
>
> Items in category 1 are things like "you can look at how long it takes
> to give you an answer to work out why" and "look at the atimes for the
> modules to see where you got vetoed". Most of these have been addressed
> some time back; I understand that John started with the Linux-PAM
> codebase, which has benefitted from a great deal of scrutiny (and
> RedHat's funding).
I'll just add a couple of things. Regarding gleaning information
from time delays, one should keep in mind that PAM doesn't add any
significant delays. Whatever delays are present or absent would
be there even if the authentication methods were built into the
applications. So PAM in and of itself doesn't introduce any new
problems in that regard. Of course, if the module is badly written
then it can cause this problem. However, the native modules that I
wrote are really just wrappers around the same code we've already
been using for years.
It's true you can get information from looking at the atimes of the
modules. But really, for many authentication methods, there are
other atimes you can look at just as profitably. Examples include
"/etc/passwd", "/etc/skeykeys", and "/etc/login.access".
> When I last discussed this with John, he indicated that he'd rejected
> just about every one of the Linux-PAM modules because of their
> manifestly awful code quality.
Yes, and also the modules tended not to port easily. And it was easy
to write new ones for our native authentication methods, because we
already had the code nicely packed up into subroutines like klogin().
> This certainly matches my experiences, and puts us in a position
> where category 2 may bite us initially simply because our modules
> don't have any road miles on them yet.
The "meat" of the native methods has lots of miles on it, since it's
our existing code wrapped up differently. But you're right about the
RADIUS and TACACS+ modules. I did my best to be very careful, but
I'll welcome the scrutiny of others with regard to potential security
problems. That particular code will enter the tree Real Soon Now
(maybe tomorrow), so it will be available to look at. Of course,
those who feel uncomfortable about the new modules can simply not use
them. They won't be included in the default "/etc/pam.conf" file.
> I still have grumbles about the monolithic nature of PAM, but it's so
> much better than what we have at the moment that I'm overjoyed to see
> it at all!
I'm glad you feel that way! I also feel that it will be a good step
forward for us.
John
---
John Polstra jdp@polstra.com
John D. Polstra & Co., Inc. Seattle, Washington USA
"Nobody ever went broke underestimating the taste of the American public."
-- H. L. Mencken
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.981111203242.jdp>