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

[Spencer Shepler]

On May 2, 2008, at 11:54 AM, 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.

I would suggest that comments about the I-D be targeted
at the NFSv4 working group.  It is an opportunity to educate
the set of NFS engineers there such that they can assist
in moving this work forward in whatever form it takes.

Spencer