by mail.netbsd.org with SMTP; 10 Jul 2000 14:31:42 -0000
	id 34E3BE0; Mon, 10 Jul 2000 10:31:39 -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
Subject: Re: group for access to the password database
Newsgroups: netbsd.tech.security
In-Reply-To: <8kc1cj$97t$1@colwyn.zhadum.de>
References: <8kc1cj$97t$1@colwyn.zhadum.de>
Reply-To: tech-security@NetBSD.ORG (NetBSD Security Technical Discussion List)
Organization: Planix, Inc.; Toronto, Ontario; Canada
Message-Id: <20000710143139.34E3BE0@proven.weird.com>
Date: Mon, 10 Jul 2000 10:31:39 -0400 (EDT)

[ On , July 10, 2000 at 08:26:59 (GMT), Matthias Scheler wrote: ]
> Subject: group for access to the password database
>
> at the moment "/etc/master.passwd" can be read by "root" only:
> 
> tron@lyssa:~>ls -l /etc/master.passwd 
> -rw-------  1 root  wheel  5821 Jul 10 09:16 /etc/master.passwd

Actually from the point of view of accessing the encrypted password the
important file is:

$ ls -l /etc/spwd.db 
-rw-------  1 root  wheel  40960 Jul  9 21:55 /etc/spwd.db

:-)

> This makes it necessary to install e.g. X11 screenlockers like "xlock"
> or "xlock" setuid "root". I wonder if it would make sense to invent
> a group "passwd" which can read but not write "/etc/master.passwd".
> Screenlockers would only have to be setgid "passwd" afterwards which
> would of course reduce the risk of security problems caused by
> such programs.

I've thought about this issue off and on for many years now (ever since
I first encountered the idea of shadow passwords and the like).

However I've yet to convince myself that adding such group access
doesn't actually increase the total risk of compromise.

If you look at it from a goal-oriented perspective this kind of "hole"
opens up an entire family of goals for an attacker.

It has taken an enormously long time (at least from my perspective)
before the majority of the world switched over to shadow passwords (and
they still haven't all, partly because of broken implementations in
systems like SunOS-4).  I'd rather not open the door again, not even one
tiny crack, to the possiblity of allowing unfettered dictionary attacks.

In fact to the contrary I've been trying come up with mechanisms of
limiting the rate at which password attempts can be made against
existing authentication tools such as login, ftp, etc.

Furthermore I think it's important to point out the fallacy in having
programs like xlock use the user's system password.  This too opens up
many avenues of attack that would be mitigated greatly by having such
programs require separate, secure, passwords.  In the past the risk with
not using the system password for things like xlock was that frustrated
users would choose a really trivial password when locking their
displays.  Now that cracklib is available to be integrated directly into
NetBSD (see my PR#10206 that's still waiting patiently for integration)
it is trivial for programs like xlock to require that users enter new
(though not necessarily unique -- that would also open an avenue of
attack) *secure* passwords.  With this scenario there's no reason to
give *any* enhanced privilege to programs like xlock and the only risk
that is increased is that people will not use them at all, but that's a
non-technical policy issue so it's moot! ;-)

-- 
							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>