From danm@prime.gushi.org  Mon Jan 27 02:19:44 2003
Return-Path: <danm@prime.gushi.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id D286E37B401
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 27 Jan 2003 02:19:44 -0800 (PST)
Received: from prime.gushi.org (prime.gushi.org [65.125.228.130])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 4CFCA43F8B
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 27 Jan 2003 02:19:44 -0800 (PST)
	(envelope-from danm@prime.gushi.org)
Received: from prime.gushi.org (danm@localhost.com [127.0.0.1] (may be forged))
	by prime.gushi.org (8.12.3/8.12.3) with ESMTP id h0RAGeZU039470
	for <FreeBSD-gnats-submit@freebsd.org>; Mon, 27 Jan 2003 05:16:40 -0500 (EST)
Received: (from danm@localhost)
	by prime.gushi.org (8.12.3/8.12.3/Submit) id h0RAGamS037876;
	Mon, 27 Jan 2003 05:16:36 -0500 (EST)
Message-Id: <200301271016.h0RAGamS037876@prime.gushi.org>
Date: Mon, 27 Jan 2003 05:16:36 -0500 (EST)
From: Dan Mahoney <freeBSDbugs@gushi.org>
Reply-To: Dan Mahoney <FreeBSDbugs@gushi.org>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: pw lock still allows access
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         47541
>Category:       bin
>Synopsis:       pw lock still allows access
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jan 27 02:20:04 PST 2003
>Closed-Date:    Mon Jan 27 02:38:12 PST 2003
>Last-Modified:  Mon Jan 27 12:40:01 PST 2003
>Originator:     Dan Mahoney
>Release:        FreeBSD 4.7-RELEASE-p1 i386
>Organization:
Gushi Systems
>Environment:
System: FreeBSD prime.gushi.org 4.7-RELEASE-p1 FreeBSD 4.7-RELEASE-p1 #0: Thu Jan 9 04:06:19 EST 2003 danm@prime.gushi.org:/usr/src/sys/compile/PRIME47 i386


>Description:

The PW man page indicates that a password locking mechanism is available via the "lock" and "unlock" commands, but should make 
mention of the fact that an admin should also check for SSH keys which may override the locked password.

>How-To-Repeat:

Create an account and configure SSH to accept key-based authentication, then try to "lock" the account with pw and attempt 
key-based login.

>Fix:

Either cause SSH (and possibly OPIE/Skey) to check for these strings in the beginning of passwords, or indicate the above in 
the manpage.



>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->closed 
State-Changed-By: mtm 
State-Changed-When: Mon Jan 27 02:28:56 PST 2003 
State-Changed-Why:  
From the man page: 

The pw utility supports a simple password locking mechanism for users; it 
works by prepending the string `*LOCKED*' to the beginning of the pass- 
word field in master.passwd to prevent successful authentication. 

The operative phrase here is "... to prevent successful authentication." 
If you are using ssh with key-based authentication, then authentication 
with the passwd database doesn't enter into it. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=47541 

From: "Matthew D. Fuller" <fullermd@over-yonder.net>
To: Mike Makonnen <mtm@identd.net>
Cc: "Dan Mahoney, System Admin" <danm@prime.gushi.org>,
	freebsd-gnats-submit@freebsd.org
Subject: Re: bin/47541: pw lock still allows access
Date: Mon, 27 Jan 2003 14:31:08 -0600

 On Mon, Jan 27, 2003 at 06:35:47AM -0500 I heard the voice of
 Mike Makonnen, and lo! it spake thus:
 > On Mon, 27 Jan 2003 06:06:12 -0500 (EST)
 > "Dan Mahoney, System Admin" <danm@prime.gushi.org> wrote:
 > 
 > > And any potential freeBSD user who needs the manpage may not know that.
 > > At the very least this should be listed in the BUGS section of the
 > > manpage.
 > > 
 > 
 > This is not a bug.
 > 
 > Again, the keyword is "authentication". The purpose of modifying/locking the
 > password field is so that the user can not use the passwd
 > database to authenticate him/herself.  This is very different from disallowing a
 > user from loging into a system. To take your specific example, there are 2 ways
 > by which a client loging into the system can ascertain that he is who he claims
 > to be: the passwd database, and ssh authentication keys.  By locking the passwd
 > entry for that user you are in effect saying the client can no longer use the
 > passwd database to login to this system. The only way he can be allowed into the
 > system is if he provides a valid ssh key.
 
 Oh, come on now...
 
 It's not a bug, it's a heads-up.  Heads-ups are not something outlawed in
 the Grand Creed Of Unix Systems.  Here's a patch.
 
 
 Index: pw.8
 ===================================================================
 RCS file: /usr/cvs/src/usr.sbin/pw/pw.8,v
 retrieving revision 1.32
 diff -u -r1.32 pw.8
 --- pw.8	12 Dec 2002 17:26:03 -0000	1.32
 +++ pw.8	27 Jan 2003 20:28:58 -0000
 @@ -801,7 +801,15 @@
  .Ql *LOCKED*
  to the beginning of the password field in
  .Pa master.passwd
 -to prevent successful authentication.
 +to prevent successful password authentication.
 +Note that this does not have impact on authentication by other means,
 +such as
 +.Pa .rhosts
 +or
 +.Xr hosts.equiv 5 ,
 +or any of the alternate forms of authentication that
 +.Xr ssh 1
 +may use.
  .Pp
  The
  .Ar lock
 
 
 
 
 -- 
 Matthew Fuller     (MF4839)   |  fullermd@over-yonder.net
 Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
 
 "The only reason I'm burning my candle at both ends, is because I
       haven't figured out how to light the middle yet"
>Unformatted:
