From owner-freebsd-security Sat May 23 11:22:04 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA17890 for freebsd-security-outgoing; Sat, 23 May 1998 11:22:04 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles231.castles.com [208.214.165.231]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA17264 for ; Sat, 23 May 1998 11:20:56 -0700 (PDT) (envelope-from mike@antipodes.cdrom.com) Received: from antipodes.cdrom.com (localhost [127.0.0.1]) by antipodes.cdrom.com (8.8.8/8.8.5) with ESMTP id KAA01275; Sat, 23 May 1998 10:10:31 -0700 (PDT) Message-Id: <199805231710.KAA01275@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Philippe Regnauld cc: Mike Smith , freebsd-security@FreeBSD.ORG Subject: Re: SKey and locked account In-reply-to: Your message of "Fri, 22 May 1998 10:12:15 +0200." <19980522101215.41390@deepo.prosa.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Sat, 23 May 1998 10:10:31 -0700 From: Mike Smith Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id LAA17282 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > Mike Smith writes: > > > I'm currently experimenting with 2.2.6, FWTK and skey. > > > > > > 1) First thing I noticed is that it's possible for someone to log > > > into the system, even if the account is disabled ('*' in the > > > passwd field), when S/Key is enabled for that user. > > > > > > Surprise to me. > > > > "*" does not disable an account - it is an invalid crypted string which > > will fail to match any crypted plaintext password, as used by login, > > the r* commands and ftp (when FTP is not using s/key). > > Ok -- just referrring to the man page: > > The password field is the encrypted form of the password. If the > password field is empty, no password will be required to gain access to > the machine. This is almost invariably a mistake. Because these files > contain the encrypted user passwords, they should not be readable by any- > one without appropriate privileges. Administrative accounts have a pass- > word field containing an asterisk `*' which disallows normal logins. > > ... it doesn't mention the fact that they _also_ have an invalid > shell. No, they don't. Administrative accounts disallow normal logins. Having an invalid shell would prevent non-normal logins. It would (perhaps) be worthwhile adding some verbiage to the description of the shell field to make it clearer that setting it to refer to /sbin/nologin is the preferred technique for preventing a user having any access to the system. The current text assumes that the reader already possesses this knowledge. Care to phrase something up and post a PR with it? -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe security" in the body of the message