[Labeled-nfs] Personal Internet-Draft for MAC support in NFSv4

[Stephen Smalley]

On Fri, 2008-05-02 at 09:54 -0700, Casey Schaufler wrote:
> --- Dave Quigley <dpquigl at tycho.nsa.gov> wrote:
> 
> > Hello,
> >     I have released a PI-D to the NFSv4 working group stating the
> > requirements and the problem statement for MAC enabled NFSv4. If you
> > want to look at the document and give comments on the requirements it is
> > located at the link below.
> > 
> > Dave
> > 
> >
> http://www.ietf.org/internet-drafts/draft-quigley-nfsv4-sec-label-requirements-00.txt
> 
> > MAC systems were traditionally relegated to "trusted" operating
> > systems and hard-coded the model behavior.  Traditional MAC models
> > used were Bell-LaPadula aka Multi-Level Security and the Biba
> > Integrity Model.  These models suffered from the need to have
> > "trusted" subjects to override the security model.
> 
> If you really want to say that I suppose there's no law against it.
> These models do not "suffer" from this need. It is intentional and
> by design. We wanted it that way. It is the right way to deal with
> violations of policy in a *ix system. Explicitly calling out cases
> where dangerous things need doing is responcible behavior. Please
> change:
> 
>     "suffered from the need to have"
> to
>     "require"   
> 
> Note the change in tense, as many of these systems are still
> widely deployed.
> 
> > They also did not
> > provide adequate protections for these "trusted" subjects.
> 
> Please delete this sentence. Both Biba integrity and B&L
> sensitivity provide protections that have been demonstrated
> and proven in systems deployed over the past 20 years.
> The assertion does nothing for your case and can only raise
> divisions within the MAC community.
> 
> > Since
> > these models were hard-coded they did not provide the flexibility to
> > represent many kinds of real security goals.  These systems also
> > neglected to take the program/code into account when defining policy
> > which play an important role when it comes to issues of trust and
> > privilege.
> 
> Earlier you said that the fact that these models required
> explictly coded "trusted" applications was a failing, yet
> here you say that the fact that they "neglected to take the
> program/code into account" is a problem.
> 
> I suggest that you take these strongly oppinionated statement
> out of this Draft. First, they don't add any value in support of
> the technology you are proposing. Second, they suggest that you
> are making a proposal that ought not to allow such behavior and
> that reduces the generality of your plan. Third, I would be
> seriously disinclined to endorse the proposal, even though I
> see no problems with the actual text, just because you insist
> on dissing many of the implementations that would benefit from
> it.
> 
> I have no problem with you targeting the proposal to SELinux.
> That is your job, after all. Ignore all the other MAC schemes
> if you must, although to be honest that is going to raise its
> own set of political issues at the IETF. But please don't
> turn this into a battlefield within our extraordinarily small
> MAC community, and especially don't do it in front of the
> children^H^H^H^H^H^H^H^HIETF.

Hi,

I don't think Dave intended the text to limit the applicability of
labeled NFS for other MAC models, and I think we can address your
concerns in the final text.

However, by way of explanation, as I understand it, we were asked to
include some background and rationale for why MAC support should matter
to the NFSv4 WG, and a key part of that is the fact that MAC is now a
mainstream security feature of general purpose operating systems.  I
don't believe that would be true if we had stayed with only the
traditional notions of MAC that were implemented in trusted operating
systems of the past.  The flexible MAC model demonstrated in SELinux
along with the SELinux project's advocacy of MAC as a useful feature for
mainstream users played an important role in gaining adoption for MAC in
mainline operating systems.

-- 
Stephen Smalley
National Security Agency