From owner-freebsd-security Tue Dec 15 09:05:37 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA20932 for freebsd-security-outgoing; Tue, 15 Dec 1998 09:05:37 -0800 (PST) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.93.229]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA19325; Tue, 15 Dec 1998 08:56:24 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.8.8/8.8.8) with SMTP id LAA19557; Tue, 15 Dec 1998 11:56:10 -0500 (EST) Date: Tue, 15 Dec 1998 11:56:09 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: John Fieber cc: Frank Tobin , FreeBSD-security Mailing List , jdp@FreeBSD.ORG Subject: Re: Limiting which users can login via xdm In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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