Date: Tue, 15 Dec 1998 11:56:09 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: John Fieber <jfieber@indiana.edu> Cc: Frank Tobin <ftobin@bigfoot.com>, FreeBSD-security Mailing List <freebsd-security@FreeBSD.ORG>, jdp@FreeBSD.ORG Subject: Re: Limiting which users can login via xdm Message-ID: <Pine.BSF.3.96.981215114710.19478A-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.05.9812151139020.44016-100000@fallout.campusview.indiana.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 15 Dec 1998, John Fieber wrote: > On Tue, 15 Dec 1998, Robert Watson wrote: > > > Presumably a login.conf module could be assembled that verified the user > > fell within the various bounds listed for their class in /etc/login.conf. > > The login(1) program currently does this to some degree. While > the authentication has been PAMified, it looks to me like a lot > more needs to be moved out into PAM account and session modules. > The simplest would be to stick it all in pam_unix, or it could be > broken down into finer grained modules. > > Does anyone already have plans for this? > > Thin it should be easy to hook xdm into this. I would assume > that the Linux crowd already have some XDM patches kicking around > for PAM.... An important step would be to seperate the pam_unix code into seperate authentication and authorization modules. The reason for this, in my mind, is that most distributed authentication systems use the same authorization code--the standard, if it's in the password file, has a good shell, etc behavior. Kerberos won't tell you if the user can log in, but will tell you if they are the user (well, authentication :). As such, I think the distinction is an important one to represent in the pam code, even though the same module can quite happily serve both functions. I think seperating it would make the behavior clearer. I'm not sure if I like the PAM session suggestion that mounting home directories is a good thing to do via PAM--however, functionally speaking, it seems like the most convenient hook. I'm also not sure I like PAM spanning the setuid() call--it's something that needs to happen but makes me uncomfortable. In a sense, it would really be preferable if things like initgroups and setuid could happen in the setcred section as part of a setcred call, but I'm not sure that's feasible for ordering reasons and to prevent accidents. In my Coda PAM module, I've been having difficulties because Coda uses a heavy-weight RPC package and threading to manage the RPCs--to acquire tokens, you have to bootstrap the threading system, which screws with signal behavior, etc. In some senses, having modules run in the same process can cause a lot of hassle. On the other hand, we don't want debuggers attaching to subprocesses and interfering with PAM. I have concluded that the best solution is to move the token acquisition into Venus and have a worker thread handle it there, using ioctls to pass along appropriate information to Venus. This way no threading happens in a module, which could interfere with other threaded code (such as a pretty xwindows-based threaded login manager). But not all authentication systems are going to be as easy to clean up for inclusion with a PAM module. Now that I've used PAM, my opinion is that it is far better than what we had before--the modularity and configurability is great. But it's not quite ideal. :) BTW, does anyone know if there is a way to tell a particular PAM application to use a different config file? I'd rather not add the Coda behavior to my system-wide pam.conf while I'm testing it :). Robert N Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon University http://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ SafePort Network Services http://www.safeport.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.981215114710.19478A-100000>