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

Ed Reed ereed at novell.com
Fri Sep 2 15:19:44 PDT 2005

Comments interspersed

>>> On Thu, Sep 1, 2005 at  2:41 pm, in message
<20050901184145.GQ7762 at shell0.pdx.osdl.net>, Chris Wright
<chrisw at osdl.org>
> * Mary Edie Meredith (maryedie at osdl.org) wrote:

> 2.3 and 2.5 are the same

>>  3 Security Capabilities
>>  	3.1 Identification and Authentication	
>>  	3.2 Access Controls (Discretionary)	
>>  	3.3 Audit, Accounting and Accountability
>>  	3.4 Mandatory Access Controls
> Is it necessary to split DAC and MAC?  Could it be:
> 3.2 Access Controls
> 	3.2.1 DAC (traditional UNIX, ACL's, etc...)
> 	3.2.2 MAC (typically lsm enforced)
>>  	3.5 Integrity Protections & Least Privilege	 
> For integrity do we bring up MLS (I ask because this may point back
> at MAC)?  For least privilege do we discuss administrative roles as
> mentioned from NFS folks (I ask because this may point back at MAC)?

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

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)

>> 	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).

>>  	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?).

>> 	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.

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.

>>  4 Security Roadmap

More information about the security_sig mailing list