Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 22 Nov 1998 21:03:34 +1300 (NZDT)
From:      Andrew McNaughton <andrew@squiz.co.nz>
To:        Don Lewis <Don.Lewis@tsc.tdk.com>
Cc:        Robert Watson <robert+freebsd@cyrus.watson.org>, 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.4.05.9811221947370.12207-100000@aniwa.sky>
In-Reply-To: <199811220606.WAA00417@salsa.gv.tsc.tdk.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

Andrew McNaughton



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.4.05.9811221947370.12207-100000>