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

Sorry this took so long. Had to get past something at work.

I think the changes address what I previously observed. Reading thru it again this morning, I did have a
question or two...and more comments. :)

1] Is a "security label" a synonym for a "MAC label"? Or are they some subset of MAC labels attached to
"security objects"?
2] Does the requirements document need to use RFC2119 requirements language? It occurred to me this
morning that there's no MUST or MAY or RECOMMENDs in this.
3] It seems to me that there might be a third mode of operation, hinted at by the use case in 4.5. The existing
"full mode" means everyone is MAC-functional, and everyone understands the same (set of) labels. The
existing "guest mode" deals with the inability of one end of a single connection to traffic in, or
interpret labels. What if, as in 4.5, all your clients are MAC-functional, groking a common labeling
scheme, and along comes a client that is still MAC-functional, but understands a different labeling
scheme? Perhaps one of the clients understands both, but the server is being super dumb and just storing
labels, not translating. How do all the servers + all the clients work out who gets access to what files?
Call this mode "Heterogeneous Labels", because it doesn't really have anythi
 ng to do with which parts of the NFS spec are implemented by the various participants. I understand that 3.4
specifies that a negotiation scheme is provided for agreeing on how they interpre
 t/translate foreign labels, but in 4.5's use case it would be two (or more) groups of clients having the
disagreement. Are the clients to negotiate directly with each other? Does the server broker the
negotiation between clients as part of being MAC-aware?  What if one of the groups of clients under the 4.5
scenario is non-MAC-aware? Can they access everything because they are free to ignore MAC labels and the
server is operating in store-and-forward mode?
4] Given #3, maybe this statement in section 3.4 needs to be strengthened.

Currently: With(in?) a given MAC model, all systems have semantically coherent labelling - a security
label must always mean the same thing on every system.

Maybe strengthened to: All systems must have semantically coherent labelling regardless of the number of
MAC models involved. (i.e., the security label must always mean the same thing on every system even if the
label presented to different systems is expressed using different MAC models.)

5] Given the (existing or strengthened) statement in #4 above, why is anything less than "Full mode"
allowed? "This label means nothing to me" is clearly a different semantic than "this label means I can
permit access under the following conditions." Yet this capability is clearly desired. It may be
worthwhile to articulate some sort of general rule, such as "Some systems may disregard labels entirely,
as long as the specified enforcement of policy occurs on a different system." Clearly, it is desirable
that "trusted systems" perform the enforcement.

6] I think the scenario described in 4.7.2.2 is asking for trouble. Sure, the client disallows access based
on its own policy...if it has a new NFSv4.2 client which is smart enough to do that. But connect with an old
client, and you have access. Now writing is another story entirely: say the client tries to store
something with a "Secret" label. An NFSv4.2 client would successfully store it, but it's sitting on a
server which can't store labels. Other clients have no idea whether it's unclassified, secret, or top
secret. This should be disallowed because it violates the general rule presented in point 5: storing the
file on a system which ignores labels prevents the enforcement of policy by a different system. In this
case, it's necessary to separate servers (same server cannot store info 
 for different security levels) and the enforcement of policy by the client becomes moot.

Bryce

________________________________________
From: Haynes, Tom [Tom.Haynes <at> netapp.com]
Sent: Friday, May 04, 2012 3:35 PM
To: Nordgren, Bryce L -FS; nfsv4 <at> ietf.org
Subject: Re: [nfsv4] WG last call complete for Requirements for Labeled NFS (still needs review)

On 5/2/12 5:17 PM, "Haynes, Tom" <Tom.Haynes <at> netapp.com> wrote:

>
>
>What I propose to do is call this out in the Security Considerations as
>you suggest.
>
>Instead of presenting the changes here, I will post a new version of the
>document.
>
>
>And again, thanks.
>

Bryce,

Could I get you to review the changes to the the Definitions part of the
Introduction and also the Security Considerations to see if these address
your security concerns?

Thanks,
Tom

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