[Security_sig] Re: DCL Capabilities section - highest level outline review

Chris Wright chrisw at osdl.org
Fri Sep 2 17:01:19 PDT 2005


* Ed Reed (ereed at novell.com) wrote:
> I'd prefer to keep DAC and MAC separate, as they're treated separately
> all the way back to the days of TCSEC, and they're so different in
> implementation.

Fair enough.

> I'm more conflicted on the question of Integrity.
> 
> TCSEC treated Integrity and Secrecy as two aspects of mandatory
> policies.  That was lost when the LSPP was created for Common Criteria,
> where Secrecy was required, but not Integrity.
> 
> I'd rather see a breakout that perhaps looks a bit more like:
> 
> 3.2 Access Controls (Discretionary)
> ...
> 3.4 Mandatory Access Controls
> 3.4.1 Secrecy (e.g. Bell-LaPadula, others)
> 3.4.2 Integrity (e.g. Biba, Type Enforcement, others)

Looks reasonable.

> >> 	3.6 Availability and Continuity of Operations
> > 
> > Is that meant to dicuss DoS mitigation?
> 
> Among other things, but also that's where I'd put backup/restore, load
> balancing, m of n quorum clusters, RAID storage strategies, etc.  This
> is an area where Security and Availability features overlap.
> 
> But access to your data when you want it IS a security concern, and
> there are many things to defend against (off-site backup, hot standby,
> automatic fail-over, process migration) that may be necessary if your
> building complex falls down (9/11) or all your power goes out (eastern
> half of the US power outage) or your data center blows away or is
> flooded (pick your hurricane).

Ah, I see your intention.  We'll need to be careful, as it's a large
topic.

> >>  	3.7 Cryptography
> >>  	3.8 Trusted Services
> > 
> > To scope the "trusted base"?
> 
> That wasn't my original intent.  Rather, the use of secure DNS, for
> instance, when possible instead of plain DNS, or the use of xntp with
> authenticated time services instead of gambling you're not being
> spoofed, etc.
> 
> Basically, extending the "trusted base" out to the critical network
> infrastructure services on which your system relies to deliver adequate
> audit (for non-repudiation:  does your time base go backwards?), and
> authentication (are you talking to that partner's CA when you ask for
> the CRL for their certificate, or someone else?).

Do you consider the trusted base plus these trusted services to be the
scope of a TOE then?

> >> 	3.9 Documentation
> >>  	3.10 Installation & Delivery
> > 
> > These last two are not likely to generate technical capability gaps,
> > rather distro issues.  They're important, but lower priority IMO.
> 
> Well, only if you don't actually care if you've configured your system
> correctly, or that your running the right software or patches, or that
> you actually know what the design (never mind the implementation) of the
> packages you're running is.

That's esp. useful for certification effort.  But then the CAPP and LSPP
efforts are required to generate that design documentation (so perhaps
other than noting its usefulness and requirement for certification
it's not a large section).  Certainly my focus is code centric, so I'm
thinking priorities start with functionality gaps.

> Basically, these are requirements for any certification process that
> hopes to address confidence that the customers knows what they're
> running.  I'd rather drive the docs requirement all the way back to each
> package, but know I have precious little hope of ever seeing that come
> to pass, except for the largest community projects.

One idea that's been tossed around is creating a repositorty for those
docs.  It's certainly one of the more (most?) expensive parts of
certification, and large portions of it should be generic (not terribly
TOE specific).



More information about the security_sig mailing list