Date: Wed, 11 Nov 1998 14:12:23 -0800 From: Mike Smith <mike@smith.net.au> To: "Jordan K. Hubbard" <jkh@zippy.cdrom.com> Cc: John Polstra <jdp@polstra.com>, Peter Wemm <peter@netplex.com.au>, cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, John Polstra <jdp@FreeBSD.ORG> Subject: Re: cvs commit: src/usr.bin/login Makefile login.c Message-ID: <199811112212.OAA05554@dingo.cdrom.com> In-Reply-To: Your message of "Wed, 11 Nov 1998 14:05:17 PST." <12368.910821917@zippy.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > recompiling a single application. Just stick it in the right place > > and add it to your pam.conf file. I think you'll like it. I know I > > do. > > 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). 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. 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. 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! -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com 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?199811112212.OAA05554>