From owner-freebsd-hackers Tue Nov 17 15:16:57 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA07038 for freebsd-hackers-outgoing; Tue, 17 Nov 1998 15:16:57 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA07003; Tue, 17 Nov 1998 15:16:52 -0800 (PST) (envelope-from karpen@ocean.campus.luth.se) Received: (from karpen@localhost) by ocean.campus.luth.se (8.9.1/8.9.1) id AAA02572; Wed, 18 Nov 1998 00:14:14 +0100 (CET) (envelope-from karpen) From: Mikael Karpberg Message-Id: <199811172314.AAA02572@ocean.campus.luth.se> Subject: Re: Would this make FreeBSD more secure? In-Reply-To: from Robert Watson at "Nov 17, 98 05:02:18 pm" To: robert+freebsd@cyrus.watson.org Date: Wed, 18 Nov 1998 00:14:14 +0100 (CET) Cc: wam@sa.fedex.com, hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL32 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG According to Robert Watson: > > 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. Yes, but this program is not a setuid program, and can be basically as incorrect as it wants. The one problem I can think of above is that the password of the user is in the buffer, but then again... the process is run as the user, and will dump core as the user. Or? > The immediate concerns that come to mind are these -- > > 1) PAM would be nice, but if not, include some kerberos code :) Sure, whatever... > 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 :). Ofcourse they are the hard ones, but they are unimportant for the discussion. > 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. If check_pw logs all failed logins, that's soon going to be noticed. :-) > 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. That's basically the same idea, I guess... you talk over a socket intead of a pipe... it's close to the same thing, at least. /Mikael To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message