From owner-freebsd-hackers Tue Nov 17 14:04:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id OAA23718 for freebsd-hackers-outgoing; Tue, 17 Nov 1998 14:04:38 -0800 (PST) (envelope-from owner-freebsd-hackers@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 OAA23534; Tue, 17 Nov 1998 14:03:26 -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 RAA26969; Tue, 17 Nov 1998 17:02:18 -0500 (EST) Date: Tue, 17 Nov 1998 17:02:18 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Mikael Karpberg cc: William McVey , hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? In-Reply-To: <199811172058.VAA02065@ocean.campus.luth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 17 Nov 1998, Mikael Karpberg wrote: > According to William McVey: > > I'm in favor of the proposed change to allow some group (for discussion > > sake, lets call it group 'shadow') read permission to the shadow file. > > Umm... I have seen no one in this discussion mention this, so I'll say it, > after repeating what someone DID say "Small well audited setuid programs > are not a problem". Now... Here's my suggestion, my_xlock.c: > > int main() { > char *str; > FILE *f; > int done = 0; > lock_screen(); /* XXXXXX */ > while (!done) { > str = wait_for_passwd(); /* XXXXXX */ > f = popen("/usr/bin/check_pw", "w"); > fprintf(f, "%d %s\n", getuid(), str); > fflush(f); > if (!pclose(f)) { > unlock_screen(); /* XXXXXX */ > done = 1; > } else { > print_errror("Wrong password"); > } > } > return 0; > } With the use of Xlib and Xwindows, the seemingly innocuous lines above go through quite a bit of work. > Seems simple enough to me, and could be used from scripts and everything. > All you need is a small util (/usr/bin/check_pw) that is setuid root. > I can't see a security problem with this, at all. Failed logins could > be logged also, if that's a concern. All it has to do is something like: > > int main() { > char buffer[100]; > struct passwd *pw; > uind_t uid; > char *str; > char *setting; > fgets(buffer, sizeof buffer, stdin); > if (isdigit(buffer[0])) { > uid = strtol(buffer, &str, 0); > if (!*str) > exit(1); > pw = getpwuid(uid); > } else { > while (!isspace(*str)) > str++; > if (!*str) > exit(1); > *str = '\0'; > pw = getpwnam(buffer); > } > str++; > setting = get_setting_and_move_str(&str); > if (strcmp(pw->pw_passwd, crypt(str, setting)) == 0) > return 0; > return 1; > } > > I'm sure there are minor or even major mistakes in the programs above, but > I think everyone should get the idea, if the problems are just syntax errors, > and such. The check_pw program should be small enough to be quite possible to > do as close to 100% bug free as one can hope to get. The immediate concerns that come to mind are these -- 1) PAM would be nice, but if not, include some kerberos code :) 2) The trivial-looking 'lock screen', 'get password', etc routines are the hard ones. I've never been pursuaded that the basic Xlib functionality is well audited (I welcome pursuasion :). 3) A check_pw command used as a client by a seperate screen saver program should be at least minimally resistant against key searching attacks. This means possibly adding sleeps, although that is fairly weak all things considering :). Just load up 60 copies of the process. 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 wrote something similar to this while playing with kernel tokens a this summer -- a daemon that serviced authentication requests (as well as authorization requests in my case). This could actually be combined with the SCM_RIGHTS behavior to allow processes to request access to ports they otherwise couldn't bind. :) 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-hackers" in the body of the message