Date: Tue, 17 Nov 1998 17:02:18 -0500 (EST) From: Robert Watson <robert@cyrus.watson.org> To: Mikael Karpberg <karpen@ocean.campus.luth.se> Cc: 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.981117165526.26891A-100000@fledge.watson.org> In-Reply-To: <199811172058.VAA02065@ocean.campus.luth.se>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.981117165526.26891A-100000>