[Security_sig] 10/14 Conf. call minutes

[Chris Wright]

* Stephen Smalley (sds at epoch.ncsc.mil) wrote:
> 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.

I agree, it should be.  However, esp. w/ the configuration complexity,
and lack of vendor integration, we actually got pushback on this (yeah,
surprised me too).  If you look at some of the assumptions posted
a while back, you'll see some really scary stuff, like protected by
physical security and implicitly trusted authenticated admins, and
network partitioning...trying to force the hand of the "DAC is enough."
One issue is that a conversation about Linux and MAC inevitably points
to SELinux as a solution when we're not interested in pushing any
particular solution.  Further it quickly hits, "too complex," "too
expensinve," "not in my enterprise," which derails the conversation
about using MAC in general.

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

Heh, sure you can.  In fact, last I checked that's what SELinux does ;-)
Unless packages come with files already labelled, you are dependent
upon pathnames for object labelling.  And even if the packaged files
are labelled, you may need to relabel based on local policy (which is
path based).  Depending on your level of paranoia even this is not
acceptable, but in practice it works.  Whether the type information
is made explicit in the configuration or is implicit hits the issue of
model flexibility vs. ease of administration.  The jury is still out on
whether simple tasks are better done with simple models.

> 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

Agreed.

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

And all the labels in the world may not stop me from opening /etc/shadow
with my privileged role, and opening an editor in my unprivileged role,
and using my eyes and the keyboard to copy the contents.  Different threat
models, different protection schemes...

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net