Xref: utzoo comp.unix.programmer:1373 alt.sources.d:1644 alt.security:2001 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!usc!aero-c!aero!faigin From: faigin@aerospace.aero.org (Daniel P. Faigin) Newsgroups: comp.unix.programmer,alt.sources.d,alt.security Subject: Re: C2 secure systems and the superuser Message-ID: Date: 19 Mar 91 20:14:13 GMT References: <19103@rpp386.cactus.org> <1991Mar13.185609.21132@convex.com> <19104@rpp386.cactus.org> <1991Mar17.060540.3911@cbnewsh.att.com> <19115@rpp386.cactus.org> Sender: news@aero.org Organization: The Aerospace Corporation, Computer Security Department, El Segundo CA Lines: 54 In-Reply-To: jfh@rpp386.cactus.org's message of 19 Mar 91 13:12:00 GMT In article <19115@rpp386.cactus.org>, jfh@rpp386.cactus.org (John F Haugh II) writes: > I tend to think that there are features above the C2 level that are > interesting in a commercial environment that would be beneficial if they > could be extracted from the remainder of the B1/B2 requirements. I think you are right. If you look at how the Canadians and Europeans have structured their criteria, you will see that features have been unbundled from assurances. > Particularly, MAC and Least Privilege. MAC is extremenly important if > information is to be protected - trojan horses can depend on DAC to permit > exporting information, but MAC prevents any unintentional downgrading of > information. Thus, management data is protected from programs gone awry. This is the critical point. I believe that once commercial companies realize the advantages of using trusted systems to protect disclosure of company proprietary, company private, and corporate secrets -- either through hierarchical levels or compartments, then the use of trusted systems in the "B" division will take off. However, the commercial side is very concerned with one aspect not addressed by the normal TCSEC, Bell-LaPadula policy -- integrity and protection of data from modification. This needs to be adequately addressed. > It doesn't have to be "full-blown" MAC, with all the requirements - just the > basic concepts of subject and object dominance. Um, what features of the *functionality* of the MAC requirements don't you need. Not that much functionality is added after B1. > I should be able to downgrade my own information so long as I am on the > trusted path. [ Guess that means I need "trusted path" too, eh? ] Not necessarily. If you were truly untrusted, how can I have assurance that what you are downgrading really should be downgraded (i.e., that you're not downgrading it just to leak it). Now, if I trust you to downgrade, I could always grant you a privilege. Funny, that's allowed under the TCSEC. > Least privilege is in there because it's just a good idea and allows > operators to be given just enough authority to get their jobs done. Yes. Note that it is contradictory to the typical Unix "root" philosophy. What the higher ratings buy you is increased assurance. Well structured kernels, reference monitors, formal verification. All of this is important if you are to be sure your system does what it will say it will do. Not that much of an increase in functionality, tho. Daniel -- [W]:The Aerospace Corp. M1/055 * POB 92957 * LA, CA 90009-2957 * 213/336-8228 [Email]:faigin@aerospace.aero.org [Vmail]:213/336-5454 Box#3149 "A consensus means that everyone agrees to say collectively what no one believes individually" -- Abba Eban