From owner-freebsd-hackers Thu Feb 13 10:58:40 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 2773B37B401 for ; Thu, 13 Feb 2003 10:58:38 -0800 (PST) Received: from murphys.services.quay.plus.net (murphys.services.quay.plus.net [212.159.14.225]) by mx1.FreeBSD.org (Postfix) with SMTP id 33B2A43F3F for ; Thu, 13 Feb 2003 10:58:35 -0800 (PST) (envelope-from trent@limekiln.vcisp.net) Received: (qmail 14672 invoked from network); 13 Feb 2003 18:58:27 -0000 Received: from limekiln.vcisp.net (212.159.16.110) by murphys.services.quay.plus.net with SMTP; 13 Feb 2003 18:58:27 -0000 Received: by limekiln.vcisp.net (Postfix, from userid 1001) id 28A125A6; Thu, 13 Feb 2003 18:58:32 +0000 (GMT) Date: Thu, 13 Feb 2003 18:58:32 +0000 From: Trent Nelson To: Julian Elischer Cc: freebsd-hackers@freebsd.org, des@freebsd.org, rwatson@freebsd.org Subject: Re: Some "security" questions. Message-ID: <20030213185832.GA63743@limekiln.vcisp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.1i 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 [ Re-sending due to earlier failure. ] On Mon, Feb 10, 2003 at 06:03:07PM -0800, Julian Elischer wrote: > > Our client wants the following 'features' > and we'd LIKE to be able to at least say "yes we can do that", even if > we can also say "but we don't think it's a good idea". > > > 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) From a security perspective, this is usually referred to as ``indi- vidual user accountability''; i.e. the ability to hold users compl- etely accountable for any actions performed under their account. The notion of ``auditing'' typically goes hand-in-hand with accoun- tability in this sense. These are recognised terms in security pu- blications such as the Information Technology Security Evaluation Criteria (ITSEC) [1]. I've been involved in generating a security solution that allowed the software engineers in the US to remotely connect to a live, op- erational, safety-related control system in London for the purposes of fault finding and software deployment. Before our Independent Safety and Technical Assessors would even consider looking at such a proposal, we had to provide assurance that every action by any user logged in remotely would always be traceable and could be reviewed for audit purposes. We could only permit remote access to the systems running Tru64 UNIX as it was the only OS that provided a fully-featured auditing sub-system that met ITSEC requirements. Tru64 UNIX will allow you to log just about any interaction with the system you fancy, from device access to system calls to command line interaction. Take a look at Section 10 of Tru64 UNIX Security [2] for more info- rmation. If acountability and auditing was to be done properly, I believe *this* is how it should be done. I've CC'd trustedbsd-audit@trustedbsd.org to this post 'cause I think this would be right up their ally. Regards, Trent. [1] Information Technology Security Evaluation Criteria Version 1.2, 28th June, 1991. (http://www.cesg.gov.uk/assurance/iacs/itsec/documents/formal-docs/media/Itsec.pdf) [2] Tru64 UNIX -- Security Version AA-RH95D-TE, June 2001. (http://www.tru64unix.compaq.com/docs/base_doc/DOCUMENTATION/V51A_PDF/ARH95DTE.PDF) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message