From owner-cvs-all Wed Nov 11 20:33:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id UAA22513 for cvs-all-outgoing; Wed, 11 Nov 1998 20:33:54 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA22508; Wed, 11 Nov 1998 20:33:51 -0800 (PST) (envelope-from jdp@polstra.com) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.1/8.9.1) with ESMTP id UAA19287; Wed, 11 Nov 1998 20:32:43 -0800 (PST) (envelope-from jdp@polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.9.1/8.9.1) id UAA00478; Wed, 11 Nov 1998 20:32:42 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.3 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199811112212.OAA05554@dingo.cdrom.com> Date: Wed, 11 Nov 1998 20:32:42 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: Mike Smith Subject: Re: cvs commit: src/usr.bin/login Makefile login.c Cc: cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG, Peter Wemm , "Jordan K. Hubbard" Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk 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