Date: Sun, 22 Nov 1998 12:05:15 -0500 (EST) From: Robert Watson <robert+freebsd@cyrus.watson.org> To: Andrew McNaughton <andrew@squiz.co.nz> Cc: Don Lewis <Don.Lewis@tsc.tdk.com>, Mikael Karpberg <karpen@ocean.campus.luth.se>, William McVey <wam@sa.fedex.com>, hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? Message-ID: <Pine.BSF.3.96.981122115625.8213A-100000@fledge.watson.org> In-Reply-To: <Pine.BSF.4.05.9811221947370.12207-100000@aniwa.sky>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 22 Nov 1998, Andrew McNaughton wrote: > On Sat, 21 Nov 1998, Don Lewis wrote: > > > On Nov 17, 5:02pm, Robert Watson wrote: > > } Subject: Re: Would this make FreeBSD more secure? > > > > } It might be nice to just have a file system socket any process can bind to > > } that mediates access to the authentication system. On the one side of the > > } socket is any client attempting to authenticate a user (possibly using PAM > > } as the API, and then some record based protocol over the socket), and on > > } the other side is Mr Auth Server that listens on the socket, accepts > > } connections, and is a place where throttling of attempts could be > > } performed. Similarly, it could take advantage of the SCM_AUTH (or > > } whatever) uid/gid passing to authenticate the processes on the other side. > > > > I think this is the best solution. Unless the process is setuid root (su), > > if the auth server sees that billybob is trying to validate a password, > > then the auth server should only validate billybob's password. This > > prevents billybob from trying to use the auth server to crack passwords, but > > it allows billybob to install and use his own private screen or terminal > > locker. > > If the server puts in a few seconds of delay for authentication of a > particular user after a failed attempt, (optionally increasing with number > of recent failures) then that's going to be enough to make brute force > infeasible. Are there any situations where it might be desirable not to > run a process as root, but where that process should be able to authorize > users using the main pw table? > > I wonder if the auth server shouldn't be dealing with more than just the > username and password. Perhaps it should also be passed enough details to > implement restrictions based on which service is being requested and the > location the request is coming from. This would facilitate a centralized > access policy. My feeling was that this could actually be extremely general purpose protocol spoken on the wire, and that it could be used in a number of situations. For example, the server could accept kerberosIV or V authenticators to check against the local rcmd for authentication. It would probably not, however, return the shared secret, as that would allow unpriveledged users to retrieve secrets from sniffed sessions. I think a PAM like functionality is best. An example of a daemon that could use this behavior is the CMU Cyrus server -- they already have a rudimentary password checker of this form (ungeneralized) so that their imap/pop servers can be spawned by inetd as the cyrus user. This way, holes in their IMAP code do not yield root access. Also, this mechanism could be used to submit password changes without a setuid binary -- the daemon, by virtue of ancillary data passing, could be aware of the remote uid, and accept an old, plus a new password, with similar delays instituted for incorrect old passwords. I started writing code to do this based on my 'kernel tokens' work -- essentially, I had a priviledged daemon acting as a token manager. Other processes, using a file system socket, could submit existing tokens and request new tokens based on them. So a kerberos ticket in a token could be used to retrieve local UID and GID tokens. When login ran, it would receive some sort or authenticating data, generate a token, send it to the tokend, and then receive back tokens authorizing it for local access to files, etc. I only partially completed the implementation (enough to allow normal users with UID/GID tokens to retrieve authorization tokens for a few specific capabilities, such as port binding), but no doubt a subset of this behavior could used without tokens. What would make people like Terry (and myself) really happy would be to make this a 'session manager' storing session keys, etc. This requires some kind of kernel integration to be useful, and that was the aspect I hoped to acquire using my token behavior. This way, samba code running in the kernel, or pseudo-user-land code such as Coda could speak to a single session manager to retrieve keys, and ask for the prompting of new keys for the user, if an interactive user was available. 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.981122115625.8213A-100000>