Date: Wed, 18 Nov 1998 00:14:14 +0100 (CET) From: Mikael Karpberg <karpen@ocean.campus.luth.se> To: robert+freebsd@cyrus.watson.org Cc: wam@sa.fedex.com, hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Would this make FreeBSD more secure? Message-ID: <199811172314.AAA02572@ocean.campus.luth.se> In-Reply-To: <Pine.BSF.3.96.981117165526.26891A-100000@fledge.watson.org> from Robert Watson at "Nov 17, 98 05:02:18 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811172314.AAA02572>