"Albert D. Cahalan" wrote:
> I think I know what he means.
>
> For "real security" you don't pretend that you can stop spies.
> The system is strictly DAC-based, and most likely uses a root
> account in the traditional way. Instead of adding new features,
> you verify that the existing ones work correctly. An LSPP/B1
> system full of bugs is worse than a perfect not-quite-C2 system.
> The latter will at least correctly enforce DAC, while the former
> might well let remote attackers get into kernel memory.
---
Absolutely agree. A DAC Protection Profile, if evaluated to
"EAL" (Evaluated Assurance Level) anything is better than an untested
system. However, CAPP and LSPP both specify an EAL of "3". This means
that their feature set has been Evaluated to meet a well-defined Level
of Assurance (documentation, testing, build methodology, code management,
some level of proof that the features provided meet the functional specs,
etc).?We've seen distro's ship binary disks where the images on the disk
didn't match what was in the source. We don't know what version of the
compiler was used, etc. We don't know what was in those
binaries -- there's no third party evaluation, no standard measured
against.
Under Common Criteria, Functional specifications are separate
from Assurance Levels. In a given Protection Profile both a set
of functional specs is given as well as a set of Assurance requirements.
The Assurance requirements are covered in Part 3 of the Common Criteria
documents (ISO standard 15408). The CC.org site seems to be down, so you
find more info at http://csrc.nist.gov/cc/ccv20/ccv2list.htm .
The Common Criteria isn't just a Dod/US gov. thing. It's also an ISO
standard. But wait, there's more -- if you call now you get these
free Ginsu Steak Knives *and* a Linux Security Policy for the unbelievable
low price...Goddess it's late...I think I better end this...:-)
Bon nuit & Au revoir,
-l
--
Linda A Walsh | Trust Technology, Core Linux, SGI
[email protected] | Voice: (650) 933-5338