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

> -----Original Message-----
> From: Haynes, Tom [mailto:Tom.Haynes <at> netapp.com]
>
> It is opaque in the sense that different implementations are free to impose
> their own format. A good example of this is a file handle. Solaris, Linux, and
> Data ONTAP all have different formats for the server generated file handles.
> And a Linux client can use all three at the same time.
>
> So yes, if you know the MAC model, you can slurp the attributes off of the
> wire and get the security attributes. To continue the example, Wireshark can
> be tricked out to display the server specific components of the file handles.
>
> You can also use krb5p to protect the attributes.
>

Ok. Got it.

>
> >
> >Section 4.7.2: While it may be true that a process running as "Secret"
> >may get denied access to a directory locally marked "Top Secret" on a
> >MAC aware client, the information is stored on a server which is not
> >MAC aware. Run the same process with the same access level on a
> >different client having access to the same directory, and it will
> >succeed. Storing data on a non-MAC aware server is "MAC-lossy". I think
> >this is sufficiently important to either create an example illustrating
> >this, or to disallow at least MLS controls (possibly all MAC controls)
> >in this situation. Most importantly, we don't want people thinking
> >they've protected something when they've only turned off their own
> >access on their own machine.
>
>
> I think what is missing here is that all of the clients have to be MAC
> functional.
>
> I've add the following paragraph to the end of Section 4.7.2:
>
>         Note that in this scenario, all of the clients must be MAC
>         functional. A single client which does
>         not do local access control checks would violate the
>         model.
>

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.

But in any case, even in the rosy world of well behaved, nonmalicious, updated clients...the clients
somehow communicate with each other directly to synchronize the MAC settings? or the non-MAC-aware
server stores-and-distributes MAC attributes it does not interpret? I did not see a method for MAC
attributes to be synchronized between two MAC-aware clients which are connected to a non-MAC aware
server. This seems like something which deserves a paragraph. (unless I just missed it.)

> I would prefer we maintain focus on the client to server interaction and leave
> the federated requirements for a different document.
>
> The replication scenario seems like a natural extension to what currently
> happens with file attributes, so I do not see a need to call it out.

Ok.

> >Finally, I don't understand how the server can trust that the process
> >on the client is what it identifies itself to be. In the good old days,
> >you just had to make a user with the owner's UID on your local machine
> >to get access to a file. Do I now only have to symlink "firefox" to
> >"vi" (etc.) to gain the desired access level? Processes can't have a
> >shared secret--particularly if they are compiled from an open-source
> >repository--and therefore, they can't authenticate themselves. It seems
> >that this scheme trusts clients too much.
>
>
> We aren't as concerned about the MAC model and the trust it grants as we
> are about supplying a transport mechanism to allow remote MAC checking.
> Ultimately, it is up to first the MAC model to determine what to check (I.e.,
> the process, UID, etc) to grant trust and finally on the security administrators
> for the site to determine if they can accept the risk of deployment.

I may not have been clear. It's the remote MAC checking itself which introduces the need to trust the NFS
client and the environment in which it is running. NFSv4 has evolved to  where the users must present
acceptable credentials directly to the server. Almost invariably, the client is not what is vouching for
the user's identity. Some LDAP or Active Directory (or SAML-via-abfab) identity store vouches for the
user, after proving its own identity. (ergo, it doesn't matter whether the client is compromised or not.)
It used to be that the client vouched for the user, but this caused all kinds of security problems because
the client is running on a system where the user might have the root password. Hence, the user could "fake"
an entry in /etc/passwd and "su" over to the fake user, gaining 
 access where they shouldn't.

I want to see that the addition of MAC controls do not constitute a reversion to this paradigm. Anything that
needs to be checked in any potential MAC model should be vouched for by something other than the (assumed
compromised) client. If a user with the root password can fake a UID, they can fake process name or anything
else. They may not even need to modify the NFS client code in order to create a compromised environment.
What they can't fake is credentials from an externally managed source. Alternatively, the NFS labeling
system should promiscuously warn all potentially affected parties that something in the MAC model
relies on the client's integrity.

To be clear, I don't know how to solve this little issue. I just see MAC controls as weaker than DAC controls,
because the DAC controls are not amenable to being faked by compromised clients...and hence to any
exploit which grants privileged access. On the other hand, if the intention is to provide a "better than
nothing" measure of control, then it's probably fine to revert to depending on the client's integrity.

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