Subject: Re: group for access to the password database
To: NetBSD Security Technical Discussion List <tech-security@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-security
Date: 07/10/2000 12:25:30
  by mail.netbsd.org with SMTP; 10 Jul 2000 16:25:33 -0000
	id C6844E0; Mon, 10 Jul 2000 12:25:30 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
From: woods@weird.com (Greg A. Woods)
To: tech-security@netbsd.org (NetBSD Security Technical Discussion List)
Subject: Re: group for access to the password database 
In-Reply-To: <20000710150101.741C835DC2@smb.research.att.com>
References: <20000710150101.741C835DC2@smb.research.att.com>
Reply-To: tech-security@NetBSD.ORG (NetBSD Security Technical Discussion List)
Organization: Planix, Inc.; Toronto, Ontario; Canada
Message-Id: <20000710162530.C6844E0@proven.weird.com>
Date: Mon, 10 Jul 2000 12:25:30 -0400 (EDT)

[ On Monday, July 10, 2000 at 11:00:51 (-0400), Steven M. Bellovin wrote: ]
> Subject: Re: group for access to the password database 
>
> *If* xlock should use the login password -- a concept which I'm dubious 
> about -- the proper solution is a mechanism to permit applications to 
> verify the password for their own UID only.

Though I've already voted against the concept of using the login
password in the likes of xlock (i.e. I agree whole heartedly with your
dubiousness! ;-), I will agree that your proposed "proper" solution is
indeed the best (only?) alternative.

I'm not sure it's worth the effort though (given that writing or
modifying any setuid program is most definitely not a trivial effort).

On the other hand there are already authentication scenarios where such
a small privileged program is used.  Such an example is Cyrus-SASL's
"pwcheck" program (formerly part of Cyrus-IMAPd).  In this particular
example the implementation is slightly different in that it uses a
secured unix-domain filesystem socket so that only authorised programs
can connect to and does the authentication on behalf of its clients much
as you describe.  Perhaps xlock could be made into a SASL client....

The question is whether there are enough such programs to make such a
server worthwhile to support as a core feature, and whether or not the
maintainers of such programs are willing to support converting to such
an authentication server, and maybe even whether or not such a server
would be picked up and used in other systems too.

(Which reminds me -- I've got pkgsrc modules for the new cyrus-sasl and
cyrus-imapd and I'm hoping the pkgsrc maintainers will take them this
time without destroying their design!  I just need to perfect the
IMAP/SSL support before I send-pr them.  Maybe Cyrus SASL would be a
good candidate for direct integration into NetBSD too.)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>