Some "security" questions.

Trent Nelson trent at arpa.com
Thu Feb 13 15:42:49 GMT 2003


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 accountability and auditing were to be done properly,
    I would definitely use Compaq's architecture as a guide.

    I've CC'd trustedbsd-audit at trustedbsd.org to this post 'cause I
    think this would be right up their alley.

    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 at trustedbsd.org
with "unsubscribe trustedbsd-audit" in the body of the message



More information about the trustedbsd-audit mailing list