[Security_sig] 10/14 Conf. call minutes

Stephen Smalley sds at epoch.ncsc.mil
Tue Oct 19 06:02:53 PDT 2004

On Mon, 2004-10-18 at 20:06, Chris Wright wrote:
> This particular DCL discussion which you refer to is about asserting
> a requirement for MAC.  MAC requirements have been in DCL yet poorly
> justified.  The purpose of this disucssion is to show that the core tier
> (specifically database, and perhaps app) servers aren't be adequately
> protected by DAC.  While we (in this group) agree on that, we actually
> found this had to be better justified.  The fact that many end-users are
> now requiring auditing (above any MAC requirements) became a discussion
> point for leveraging a MAC requirement to protect the integrity of the
> audit subsystem.

Simply protecting the database or app server (code and data integrity,
unbypassability, strong binding of privilege to code) should be
sufficient motivation for MAC in that context, even apart from any audit
subsystem.  Further, as database servers often require special
privileges, the ability to grant such privileges at fine granularity
should be further justification for MAC.

> This is one key issue, and it is a reality that people report finding
> SELinux difficult to use.  I wouldn't go so far to say equivalence
> classes are _required_ to enforce higher level security goals -- perhaps
> it depends on definition of higher level.  However, I do agree that the
> abstraction is needed for anything that's complex and general purpose
> (i.e. securing a general purpose system w/out added abstraction is
> asking for major holes, and no possible formal way to convince yourself
> of policy closure).  However, that's moot, considering the question is
> about justification of MAC requirement,

It may be moot in this particular discussion, but it is true.  You can't
enforce information flow control for confidentiality or integrity
purposes based on pathnames.  If you want any confidence of preventing
leakage of sensitive information or corruption of high integrity
information, then you need to tag subjects and objects with their
security properties and control the flow of data based on those tags,
whether you call them types or levels or whatever.  Protecting
/etc/shadow against direct access does nothing to prevent leakage of its
data from programs that are allowed to read it through shared resources
accessible to other processes or to prevent corruption of its contents
as a result of low integrity data sources flowing into programs allowed
to modify it.

> Thanks for your input.

Thanks for the constructive feedback.

Stephen Smalley <sds at epoch.ncsc.mil>
National Security Agency

More information about the security_sig mailing list