wcs) (03/17/91)
In article <19104@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes: > Naive users do not fully understand what the difference between a "rated" > and an "unrated" system are - there are very real differences and One of the major differences is that the NCSC doesn't really have the resources to formally evaluate every product that wants it - you've got to have something new and interesting to offer, and be willing to wait about 1.5 - 2 years AFTER convincing them to bother with you, and evaluation is for specific hardware configurations as well as software. Most of the market is satisfied with C2 functionality, and doesn't really need the NSA Good Housekeeping Seal. This is especially important, since adding networking affects your Trusted Computing Base, and throws you out into uncharted Red Book territory, even at C2 level. Most customers would really rather have networking now, hopefully with the bigger holes patched, rather than wait until the general research problem is solved well enough for the NCSC to certify systems. (Remember that even Verdix is just a "component", not a complete system.) > To continue with the real topic, "C2" is not that "secure" of > a rating. If you expect the system to warn you of auditable > events which might indicate a violation of the security policy > you have to go to a higher level. The only rating level between > "C2" and MS-DOS is "C1". There are still 3 "B" levels and an > "A" level above "C2". The description of "C2" is [ C1 + Good Auditing/Accountability + Object Reuse prevention ] Well, there's also D level; the TCSEC definition says: Level D: Thank you for sharing that. :-) All of the levels add increasing amounts of assurance. The interesting additions at B1 are Mandatory Access Control - you get the equivalent of "Unclassified/Secret/TopSecret", with system enforcement so users can't just give stuff away. If you trust your users, or don't trust your superuser, this doesn't buy you much extra, though you can gain some significant protection by giving the system software and audit trails their own classification levels, which regular users (or bugs) can't touch. B2 adds Trusted Path, Covert Channel Analysis, and Least Privilege, and starts to feel less like Real Unix, because you don't really have One All-Powerful Root any more. Covert channel analysis is a real problem - something that was adequate protection on a 1 MIPS box may not do the job on a 200 MIPS multi-processor with a 500 MFLOPS add-on vector board. -- Pray for peace; Bill # Bill Stewart 908-949-0705 erebus.att.com!wcs AT&T Bell Labs 4M-312 Holmdel NJ # Hacker. System Designer. Troublemaker.
faigin@aerospace.aero.org (Daniel P. Faigin) (03/18/91)
In article <1991Mar17.060540.3911@cbnewsh.att.com>, wcs@cbnewsh.att.com (Bill Stewart 908-949-0705 erebus.att.com!wcs) writes: > Most of the market is satisfied with C2 functionality, and doesn't > really need the NSA Good Housekeeping Seal. Correction. Most of the COMMERCIAL market. The ratings are there to help the DoD side of things. This goes along with the Agency's charter. If it ever gets the budget, the commercial side will probably be happer with NIST. > This is especially important, since adding networking affects your Trusted > Computing Base, and throws you out into uncharted Red Book territory, even > at C2 level. I wouldn't say the TNI (red book) is uncharted. It is a different way of thinking. It is charted, as there are evaluations working against it. > Most customers would really rather have networking now, hopefully with the > bigger holes patched, rather than wait until the general research problem is > solved well enough for the NCSC to certify systems. The NCSC does not certify systems. That is up to the accrediting agency that determines that the residual risk for a particular system in a particular installation is acceptable. The NCSC only rates systems. As for networks, yes, it is a problem that many systems on the EPL do not support real-life configurations. Vendors also have to accept a risk when they go into "uncharted territory". If systems don't get submitted in real-life configurations, they don't get evaluated in real-life configurations. What happens in real-life is that the accreditor must look at the changes to the system from the EPL configuration, and decide that the risk is acceptable. For this to be "a good thing", the accreditor must be given (and be capable of understanding) the nuances of the additional information. > B2 adds Trusted Path, Covert Channel Analysis, and Least Privilege, and > starts to feel less like Real Unix, because you don't really have One > All-Powerful Root any more. More importantly for Unix, B2 adds requirements in the area of system architecture that make it difficult, if not impossible, for retrofitted Unix systems. 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
jfh@rpp386.cactus.org (John F Haugh II) (03/19/91)
In article <FAIGIN.91Mar18121748@sunstroke.aerospace.aero.org> faigin@aerospace.aero.org (Daniel P. Faigin) writes: >In article <1991Mar17.060540.3911@cbnewsh.att.com>, wcs@cbnewsh.att.com (Bill >Stewart 908-949-0705 erebus.att.com!wcs) writes: > >> Most of the market is satisfied with C2 functionality, and doesn't >> really need the NSA Good Housekeeping Seal. > >Correction. Most of the COMMERCIAL market. The ratings are there to help the >DoD side of things. This goes along with the Agency's charter. If it ever gets >the budget, the commercial side will probably be happer with NIST. 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. 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. It doesn't have to be "full-blown" MAC, with all the requirements - just the basic concepts of subject and object dominance. 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? ] 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. -- John F. Haugh II | Distribution to | UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 | GEnie PROHIBITED :-) | Domain: jfh@rpp386.cactus.org "I've never written a device driver, but I have written a device driver manual" -- Robert Hartman, IDE Corp.
faigin@aerospace.aero.org (Daniel P. Faigin) (03/20/91)
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