Re: WG last call complete for Requirements for Labeled NFS (still needs review)

Please forgive stupid quoting. I'm using Outlook Web App and there's no obvious way to make it "normal".

Quoted text is between these: >>>
>>>
________________________________________
From: Haynes, Tom [Tom.Haynes <at> netapp.com]

>This brings up a good point: should a non-MAC-aware server be required to
>either enforce the enforceability of a MAC security model (e.g., by only
>allowing connections from MAC-aware clients) or detect when the model
>could be violated (e.g., by noting that the directory is being accessed
>by a mixture of MAC-aware and non-MAC-aware clients)? How is one client
>to know if there is another client out there which will ignore the
>controls it attempts to specify? If all I gotta do to get access to data
>I shouldn't have is to run an old non-MAC-aware client...and never run
>the risk of being detected...this doesn't bode well.

Bryce, one of our intents is not to describe how the client or server
makes MAC decisions. As you suggest, a server could implement a policy to
only hand out objects with labels iff the client presented a subject label
in the RPCSEC_GSSv3 layer.

My view of a server which transports and stores labels is it is either:

1) A debugging mode to allow server implementors to ensure they have
implemented the transport and storage correctly.

2) A simple but effective means to solve the seVirt use case for
proprietary servers which have yet to implement a MAC system.

>>>

Ahhh, in this case, I think the text needs formal definitions of "MAC functional" (used in section 4.7) vs
"MAC aware" (used in section 3.7). I took them to be synonyms, but it looks like you mean:

MAC Aware: Client/Server is LNFS-enabled and requirements in this document apply. Non-MAC aware would
indicate that the server/client do not satisfy LNFS requirements.

MAC Functional: Client/Server is MAC-Aware, and labels are interpreted. A non-MAC-functional system
remains MAC-aware, but does not interpret labels.

>>>

I don't want to mention the need for a callback, but would explaining the
above requirement clear up your concern?

>>>

I think adding the above definitions would clear this up too.

>>>
I want to be very upfront about the fact that the document is based on the
assumption that the server trusts the client. We adopted that from the
work Carter reported at
http://www.nsa.gov/research/_files/selinux/papers/nfsv3.pdf. But that
assumption holds only as much as the MAC implementation on the server
allows it to exist.
>>>

I think this should go in the introduction...or in a scope statement.

>>>
Just as with your user credential example, these types of security models
depend on implementations and site security administrators enforcing them.
There are plenty of NFSv3/v4 installations in the wild that still use
/etc/passwd or NIS for credentials.

And as much as we do not recommend it, people might want to deploy either
LNFS or server-side copy without also using RPCSEC_GSSv3. They can also
decide to not use kerberos.
>>>

I'm less concerned about lazy system administrators than the ability of users to easily overcome the
efforts of diligent administrators. :)

However, this is a broader question which is apparently the focus of RPCSEC_GSSV3. Given this, I would
recommend explicit references to RPCSEC_GSSV3, highlighting its features and their role in reducing
the need to trust the client. I would also highlight exactly what you said to me in an earlier email: a user
with root access has access to the clients' credentials. This perhaps belongs in an example, as a
"preferred configuration". At the very least, I think this topic deserves a nod in the Security
Considerations section.

With these changes, I think it looks good.

Bryce

This electronic message contains information generated by the USDA solely for the intended recipients.
Any unauthorized interception of this message or the use or disclosure of the information it contains may
violate the law and subject the violator to civil or criminal penalties. If you believe you have received
this message in error, please notify the sender and delete the email immediately.

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www.ietf.org/mailman/listinfo/nfsv4