From owner-freebsd-hackers Mon Feb 10 23:59:56 2003 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0A46A37B401 for ; Mon, 10 Feb 2003 23:59:55 -0800 (PST) Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0F7743F3F for ; Mon, 10 Feb 2003 23:59:53 -0800 (PST) (envelope-from des@ofug.org) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 423D3536E; Tue, 11 Feb 2003 08:59:49 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Julian Elischer Cc: hackers@freebsd.org Subject: Re: Some "security" questions. From: Dag-Erling Smorgrav Date: Tue, 11 Feb 2003 08:59:49 +0100 In-Reply-To: (Julian Elischer's message of "Mon, 10 Feb 2003 18:03:07 -0800 (PST)") Message-ID: User-Agent: Gnus/5.090014 (Oort Gnus v0.14) Emacs/21.2 (i386--freebsd) References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Julian Elischer writes: > 1/ Command logging. We're thinking that a hacked version of the shell > that logs commands may do what they want, but personally I > think that if you are going to log things then you really want to > PROPERLY do it, and log the EXEC commands along with the arguments. > (sadmin et al. doesn't give arguments, and neither does ktrace) "Yes, we can do that" in the sense that it can be implemented if there's a demand for it, but I don't think any existing code can do it. > 2/ they want to disable a login if it fails 'n' sequential logins > anywhere in the system. i.e. 2 on one machine followed by another on > another machine. "Yes we can do that" with a smart PAM module. > I can immagine using pam_radius, and hacking a radius server > to track login fails.. Anyone have any better ideas? > Maybe a pam_module specially written? (hmmmm) PAM has a mechanism which allows for arbitrary named objects to be stored for the duration of a PAM transaction, along with a destructor which is called when the object is released (either explicitly or when the transaction ends). You could write a PAM module which stores an object in the authenticate phase, then modifies its contents in the setcred phase (which only occurs if authentication was successful). The destructor would register success or failure in a database depending on whether the object was modified before release. The exact nature of that database is not important. DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message