Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbfsb!cbnewsc!tjr
From: tjr@cbnewsc.att.com (thomas.j.roberts)
Newsgroups: comp.unix.programmer
Subject: Re: C2 secure systems and the superuser
Message-ID: <1991Mar14.165015.25728@cbnewsc.att.com>
Date: 14 Mar 91 16:50:15 GMT
References: <1991Mar13.185609.21132@convex.com>
Organization: AT&T Bell Laboratories
Lines: 27

I have not seen all of this thread, but I have not seen anyone point this out:

SOMEBODY on the system has to do dumps/restores/authorization changes/etc.
Calling this account "root", or splitting it up into several accounts
with restricted (but "root-like") privileges has no security relevance,
as one such privileged account can usually use its privileged operation
to mimic the others (I suspect there is a closure principle here).
Yes, audit logs can be modified by somebody clever and motivated enough.
Yes, if you give an untrustworthy person access to a privileged account
you can be in trouble. THERE IS NOTHING THE COMPUTER SYSTEM CAN DO ABOUT
THIS - it is inherent in the situation. An abstract (C2-evaluated)
trusted system alone cannot be trusted to protect the security of its data
- you must evaluate not only the operating system, but also HOW
IT WILL BE USED, WHO WILL USE IT, WHO WILL ADMINISTER IT, ETC.
The NSA's Computer Security Center knows this - look at the "rainbow books"
(the "orange book" is NOT sufficient). Any C2 system will have considerable
lattitude in setup - if an organization is concerned about the modification
of audit trail logs, they will take steps OUTSIDE of the operating system
to ensure they are not modified (such as a "two man" rule, hardcopy audit
trail logs, etc.).

In practice, the "strength" of the operating system IS NOT the problem -
administrative practices are usually the weak point of a system.

Tom Roberts
AT&T Bell Laboratories
att!ihlpl!tjrob  TJROB@IHLPL.ATT.COM