Date: Tue, 11 Feb 2003 08:59:49 +0100 From: Dag-Erling Smorgrav <des@ofug.org> To: Julian Elischer <julian@elischer.org> Cc: hackers@freebsd.org Subject: Re: Some "security" questions. Message-ID: <xzp65rrmemi.fsf@flood.ping.uio.no> In-Reply-To: <Pine.BSF.4.21.0302101752500.49102-100000@InterJet.elischer.org> (Julian Elischer's message of "Mon, 10 Feb 2003 18:03:07 -0800 (PST)") References: <Pine.BSF.4.21.0302101752500.49102-100000@InterJet.elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer <julian@elischer.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzp65rrmemi.fsf>