From owner-freebsd-arch Sat Mar 9 12:34:49 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id BEDF637B404; Sat, 9 Mar 2002 12:34:44 -0800 (PST) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g29KYhVu137732; Sat, 9 Mar 2002 15:34:43 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Sat, 9 Mar 2002 15:34:42 -0500 To: arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: Fix for login.c, added questions Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 2:57 PM -0500 3/9/02, Garance A Drosihn wrote to freebsd-audit: >In my testing, the simple fix is: > >Index: login.c Reading thru login.c, it seems to me that we should probably consider some other changes too. One thing I noticed, for instance, is that login.c tries to setup a 300-second timeout, but apparently that timeout is masked off somewhere inside the auth_pam() processing. So, if a person types in a login name, a wrong password, types in the same login name and then just sits in the next password prompt, the session (apparently) never times out. Or at least it doesn't seem to have timed out for me in the more than 20 minutes I've left it sitting there on a console login. One thing the code tries to do is avoid a syslog message for the case of: login myid wrong password login myid correct password My claim is that this goal complicates the code enough that it also opens up some subtle opportunities for nefarious souls to be guessing passwords without syslog messages occurring. For one, it means you have to delay writing the syslog message at least until you read in the new userid, which is under the control of the very user who (perhaps) is trying to do something nasty. Do people think we could drop the nice idea of avoiding the syslog message in the above situation, and just always write out the syslog message right when we know the password is wrong? That will increase the number of syslog messages, which might alarm some users, but I think it's safer. Perhaps we could avoid that alarm by also writing out a syslog message if the session gives the correct password for a userid after having given a failed password. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message