From owner-freebsd-security Thu May 21 21:00:25 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id VAA19434 for freebsd-security-outgoing; Thu, 21 May 1998 21:00:25 -0700 (PDT) (envelope-from owner-freebsd-security@FreeBSD.ORG) Received: from antipodes.cdrom.com (castles145.castles.com [208.214.165.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id VAA19423 for ; Thu, 21 May 1998 21:00:15 -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 TAA06636; Thu, 21 May 1998 19:56:16 -0700 (PDT) Message-Id: <199805220256.TAA06636@antipodes.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: Mike Fisher cc: freebsd-security@FreeBSD.ORG Subject: Re: SKey and locked account In-reply-to: Your message of "Thu, 21 May 1998 23:22:48 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 May 1998 19:56:16 -0700 From: Mike Smith Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk > On Thu, 21 May 1998, Mike Smith wrote: > > > If you wish to disable a user's account, you should set their shell to > > something nonexistent. (Note that ssh may still be a way past this.) > > As is the login.conf(5) database, from what I can tell. If the disabled > user drops in a .login_conf that sets the shell, it will work although > they will need to modify their SHELL environmental variable if they're > going to be doing much fun stuff. > > However, I just did some playing around with this on a 2.2.6-STABLE system > and didn't seem to have any luck subverting the configured shell. (Read: > assuming I configure .login_conf correctly, it is not being used > correctly.) from login.conf(5) In FreeBSD, users may individually create a file called .login_conf in their home directory using the same format, consisting of a single entry with a record id of "me". If present, this file is used by login(1) to set user-defined environment settings which override those specified in the system login capabilities database. Only a subset of login capabili- ties may be overridden, typically those which do not involve authentica- tion, resource limits and accounting. In addition, the 'shell' capability seems to be unimplemented. 8( > With SSH, I was unable to do a login via RSA keys or password > authentication with the shell set to /sbin/nologin. I'd assume that the > ..shosts authentication would also be effectively broken. That's bad, and effectively a bug in ssh. -- \\ 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