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

[Casey Schaufler]

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

Thank you.


Casey Schaufler
casey at schaufler-ca.com