Subject: Re: [nfsv4] WG last call complete for Requirements for Labeled NFS (still needs review)

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Tue, 1 May 2012 14:16:01 +0000

I'm not officially IETF, but I have some feedback.

Section 3.2, paragraph 3: "LNFS should be respond in a robust..." (bad grammar)

Section 3.4: "To accomplish this, the labels should consist of an opaque component bound with a Label Format Specifier. The opaque component consists of the label which will be interpreted by the MAC model on the other end while the LFS provides a mechanism for identifying the structure and semantics of the label's components."  (It sounds to me that the LFS defines the structure of the "opaque" part, therefore making it possible for anything to interpret it. If this is the case, you really don't have an "opaque" part because the format is well understood by all. e.g., feed the "opaque part" and the format string to a specialized version of sscanf() to get your security attrs. This may not be what you mean, but it's the only thing I can think of which matches this description.)

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.

In terms of what is missing, I did not see any mention of how (or if) multiple servers coordinate MAC annotations for "replicas". I saw much talk of client-server interaction, and nothing of server-server interactions. How does a cluster of servers hosting replicas of the same object coordinate the access controls on that object? Particularly if those servers are owned by different administrative entities, as in a filesystem federation?

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.

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.

---

From: "Haynes, Tom" <[email-masked]>
Date: Tue, 1 May 2012 15:57:17 +0000

>I'm not officially IETF, but I have some feedback.

I doubt anyone is officially IETF - volunteering to help is what it is all
about.

So thanks!

>Section 3.2, paragraph 3: "LNFS should be respond in a robust..." (bad

Fixed

>
>Section 3.4: "To accomplish this, the labels should consist of an opaque
>component bound with a Label Format Specifier. The opaque component
>consists of the label which will be interpreted by the MAC model on the
>other end while the LFS provides a mechanism for identifying the
>structure and semantics of the label's components."  (It sounds to me
>that the LFS defines the structure of the "opaque" part, therefore making
>it possible for anything to interpret it. If this is the case, you really
>don't have an "opaque" part because the format is well understood by all.
>e.g., feed the "opaque part" and the format string to a specialized
>version of sscanf() to get your security attrs. This may not be what you
>mean, but it's the only thing I can think of which matches this
>description.)

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.

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

>
>In terms of what is missing, I did not see any mention of how (or if)
>multiple servers coordinate MAC annotations for "replicas". I saw much
>talk of client-server interaction, and nothing of server-server
>interactions. How does a cluster of servers hosting replicas of the same
>object coordinate the access controls on that object? Particularly if
>those servers are owned by different administrative entities, as in a
>filesystem federation?

These are very interesting questions.

For the replication, the attribute on the master copy will be propagated
to the replicas using whatever mechanism the servers employ.
If it is modified, then I would expect it to change as would say a write
to the object.

Further, I would expect that the given MAC model might restrict some
replication to different entities of the federation.

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.

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

>
>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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/nfsv4

---

From: "Haynes, Tom" <[email-masked]>
Date: Tue, 1 May 2012 16:17:38 +0000

On 4/30/12 11:32 PM, "Dave Quigley" <[email-masked]> wrote:

>On 4/30/2012 2:55 AM, Spencer Shepler wrote:
>> We have completed the last call for the Labeled NFS.
>>
>> While this is a short document and certainly has had a lot of feedback
>> over its lifetime, I do not believe this particular version is ready to
>> forward to our AD.
>>
>> I need to have at least two reviewers for this version before I will
>> shepherd it forward. Given this is a requirements document and it deals
>> with security and it is providing a path for our NFSv4.2 work, I want it
>> to be ready for the broader IESG review.
>>
>> Thanks in advance for the help.
>>
>> Spencer
>>
>>
>>
>Here are my comments come up with.
>
>Section 1
>
>This might be splitting hairs so I leave it up to others to decide but
>technically Windows Vista/Windows 7 does not provide mandatory access
>controls. They have a mandatory integrity model but not access controls.
>Their access control model is squarely in the DAC category.

Removed the technicality.

>
>Section 3.4 First paragraph
>
>The sentence "The opaque component consists of the label which will be
>interpreted by the MAC model on the other end...." That last part just
>reads weirdly to me. I'm not sure how to change it or if it needs to but
>reading over it several times it just doesn't read well to me.

-      The opaque component consists of the label which will be
interpreted by the MAC
-      model on the other end while the LFS provides a mechanism for
identifying the
-      structure and semantics of the label's components.

versus

+      The LFS component provides a mechanism for identifying the
structure and semantics of the
+      opaque component.  Meanwhile, the opaque component is the security
label which will
+      be interpreted by the MAC models.

>
>Section 3.5
>
>In modes of operation we don't describe what we use to refer to a dumb
>mode. We have guest mode in here but I don't read anything in the
>section which says that the server may provide labeling without
>enforcing a policy and the client may still enforce policy on its end.
>Maybe its late and I'm missing something but I tried reading it over and
>couldn't find anything which would enable the use case in section 4.5
>which is simple security label storage.

I think you want this section:

4.5.  Simple security label storage

We also mention it in here:

3.9.  Upgrading Existing Server

Do you want to pull it out of the Use Cases and into the modes?

>
>Section 4.7 with subsections
>
>It seems weird to have such a large section describing MLS semantics. It
>was important when it was one of two use cases but is it still
>necessary? I'm ok with leaving it in but it seems out of place that we
>have over a full page for that one use case while everything else gets
>two or three paragraphs.

It is the easiest for non-security people to understand?

>
>
>That is all I could find. Everything else is very polished and reads
>well. I'm glad we were able to put together such a good document.

---

From: <[email-masked]>
Date: Tue, 1 May 2012 15:03:01 -0400

How about the following for section 3.4, to avoid a non-terminating 
discussion of opacity as a concept?

    To accomplish this, the labels should consist of a nominally
    opaque component bound with a Label Format Specifier. The 
    nominally opaque component consists of the label which will not
    be interpreted or known by XDR but which will be interpreted by the  
    MAC model on the other end while the LFS provides a mechanism for 
    identifying the structure and semantics of the label's components.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Haynes, Tom
Sent: Tuesday, May 01, 2012 11:57 AM
To: Nordgren, Bryce L -FS; [email-masked]
Subject: Re: [nfsv4] WG last call complete for Requirements for Labeled NFS (still needs review)

So thanks!

Fixed

---

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Tue, 1 May 2012 20:11:14 +0000

> From: Haynes, Tom [mailto:[email-masked]]
>
> 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.
>
> 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.
>

Ok. Got it.

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

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

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

---

From: Jarrett Lu <[email-masked]>
Date: Tue, 01 May 2012 13:53:54 -0700

Tom, Spencer,

The document is in pretty good shape. My review comments and questions 
are as follows:

1. Section 3.3 list the following Security Services:
- Authentication
- Integrity
- Privacy

I'd expect Confidentiality be listed as well, as many MAC systems do 
provide confidentiality. Is Privacy used here to mean Confidentiality?

2. Through out the document, "local server policy" and "local client 
policy" are used. It may be better to eliminate the word "local" and 
just use "server policy" and "client policy". Server and client policies 
may not be strictly "local" as the policies can reside in a centralized, 
networked database, which could make policy configuration and 
administration easier.

3. Section 3.4,
In "If the LFS of a system changes", it's probably more clear to state 
"If the LFS supported on a system changes".
An LFS, i.e. the label format mapping, probably won't change. A system 
may be reconfigured to support more or less LFSs.

4. Section 3.6,
    The content of the paragraph seems to suggest that the section title 
should be "Label Checking" instead of "Labeling".

5. Section 3.9,
The example usage of LFS here is incorrect. LFS indicates what label 
format is used and how labels should be interpreted. It is not meant to 
be used to indicate server capability or its smartness in handling 
labels, such as "I'm only capable of storing and returning labels".

6. Section 4.2,
double word "able to to protect".

7. Section 4.5,
The reference to case (a) should be removed.

8. The draft referenced by this doc, "Registry Specification for MAC 
Security Label Formats", just expired. David Q and I should move that 
draft forward.

Thanks.

- Jarrett

On 04/30/12 12:43 PM, Spencer Shepler wrote:
> Thanks, Jarrett and Dave.  Please go ahead with the review and let me know when you are finished.
>
> I would like to have one more volunteer that has been at least once removed from the material for a read of flow of the document and to see if there are any "missing"pieces.
>
> Volunteers?
>
> Spencer
>
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Jarrett Lu
> Sent: Monday, April 30, 2012 6:15 AM
> To: Dave Quigley
> Cc: [email-masked]
> On Apr 30, 2012, at 5:13 AM, Dave Quigley<[email-masked]>  wrote:
>
>>> While this is a short document and certainly has had a lot of
>>> feedback over its lifetime, I do not believe this particular version
>>> is ready to forward to our AD.
>>>
>>> shepherd it forward. Given this is a requirements document and it
>>> deals with security and it is providing a path for our NFSv4.2 work,
>>> I want it to be ready for the broader IESG review.
>>>
>> Does this have to be revewiers besides myself? I can be one of them and we've had a review from Casey Schaufler on the SELinux list that I had forgotten to forward over here. If you'd like We could be the two. If someone else besides me needs to do it I'll get Steve Smalley to chime in on the draft.
> I can be one of the reviewer too.
>
> - Jarrett
>
>
>> Dave

---

From: Nico Williams <[email-masked]>
Date: Tue, 1 May 2012 15:56:47 -0500

>>It seems weird to have such a large section describing MLS semantics. It

IMO we shouldn't have *any* text describing MLS or any other labeled
security semantics.  The protocol shouldn't care.  Of course, we may
need a required to implement labeled security domain of
interpretation, but it's not clear to me that MLS should be it.

Alternatively, describing a number of schemes might help some readers.

I'd classify labeled security semantics roughly into two broad
classes: ones with strictly algorithmic label rules (e.g., MLS), and
ones with not strictly algorithmic (and even strictly non-algorithmic)
label rules (e.g., SMACK).  This, I think, makes it easy to explain.

Anyways, to me it seems simple to say that labeled security always
involves a decision based on a subject's label, and object's label,
and requested access.  How that decision is made is what makes MLS,
DTE, ... what they are -- they all differ in this one key question,
but it should not be necessary to understand each scheme to understand
labeled security in the first place.

Nico
--

---

From: Jarrett Lu <[email-masked]>
Date: Tue, 01 May 2012 14:01:26 -0700

On 04/30/12 09:32 PM, Dave Quigley wrote:
> Maybe its late and I'm missing something but I tried reading it over 
> and couldn't find anything which would enable the use case in section 
> 4.5 which is simple security label storage.

Doesn't the standard NFS4.2 server do this, i.e. the server just 
stores/retrieves the label attribute without interpretation or enforcement?

- Jarrett

---

From: "Haynes, Tom" <[email-masked]>
Date: Tue, 1 May 2012 21:31:13 +0000

>The document is in pretty good shape. My review comments and questions

Thanks for the review.

>provide confidentiality. Is Privacy used here to mean Confidentiality?

Yes, these are actually the offerings of krb5. So the context is the
network and not the MAC system.

>networked database, which could make policy configuration and

Agree, "local" seems to be used instead of "its". Changed most of the
occurrences of "local".

>may be reconfigured to support more or less LFSs.

Changed

>should be "Label Checking" instead of "Labeling".

Changed.

>labels, such as "I'm only capable of storing and returning labels".

Ok, I had already changed this to be:

      In this case, a mixed and loosely administered network is assumed,
      where nodes may be running a variety of operating systems with
      different security mechanisms and security policies.  It is desired
      that network file servers be simply capable of storing and retrieving
      MAC security labels for clients which use such labels.  The LNFS
      protocol would be implemented here solely to enable transport of
      MAC security labels across the network.  It should be noted that in
      such an environment, overall security cannot be as strongly enforced
      as when the server is also enforcing, and that this scheme is aimed
at
      allowing MAC-capable clients to function with its MAC security
policy enabled rather
      than perhaps disabling it entirely.

But, in your registry document, we planned to reserve a LFS of 0 to mean
that the server is only capable of storing and returning labels.

>double word "able to to protect".

Fixed.

>The reference to case (a) should be removed.

Fixed.

>> I would like to have one more volunteer that has been at least once
>>removed from the material for a read of flow of the document and to see
>>if there are any "missing"pieces.
>>
>> Volunteers?
>>
>> Spencer
>>
>>> Does this have to be revewiers besides myself? I can be one of them
>>>and we've had a review from Casey Schaufler on the SELinux list that I
>>>had forgotten to forward over here. If you'd like We could be the two.
>>>If someone else besides me needs to do it I'll get Steve Smalley to
>>>chime in on the draft.

---

From: "Haynes, Tom" <[email-masked]>
Date: Tue, 1 May 2012 21:34:33 +0000

>interpretation, but it's not clear to me that MLS should be it.

Yes, in the protocol description there should not be any mention of MLS
semantics. It should just describe the transport changes necessary to
convey labels.

This is however the Requirement's Document and it is valid to describe
some parts of schemes to help people see how we plan to facilitate these

---

From: Jarrett Lu <[email-masked]>
Date: Tue, 01 May 2012 15:07:17 -0700

>        than perhaps disabling it entirely.

OK. The above text looks good.

> that the server is only capable of storing and returning labels.

LFS of 0 is reserved. Why can't a server pick a different value?

- Jarrett

---

From: "Haynes, Tom" <[email-masked]>
Date: Tue, 1 May 2012 23:08:48 +0000

On 5/1/12 3:11 PM, "Nordgren, Bryce L -FS" <[email-masked]> wrote:

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

In particular, I do not envision Linux nor Solaris ever implementing it as
they already have working MAC systems.

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

One of the requirements of even such a limited server is bullet (3) of the
Introduction:

   (3)  Server must provide a mechanism for notifying clients of
       attribute changes of files on the server.

This means that if client A modifies the object label of a file and client
B has that file open, then the server MUST inform client B that the label
has changed. In the implementation, this would be via a callback,
CB_ATTR_CHANGED. When client B is notified of the label change, it is
required to retrieve the new label from the server and start to use it
immediately.

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

>>(I.e.,
>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.

First, I want to thank you again for your comments - I believe they are
going to be representative of what we face when we open the document up to
a wider audience.

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.

The server is free to use whatever it wants to do the MAC checks, I.e., it
does not just have to depend on the subject label. It could for example
examine the IP address or the user credentials as well as the subject
label.

Further, the subject label could be a token that the client gets from an
externally managed source. When it is presented to the server, it could in
turn validate that token against the externally managed source.

But our mandate here is not to dictate how servers enforce MAC policies.
The communication with an externally managed source falls way outside the
realm of the NFSv4 protocol.

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.

---

From: Nico Williams <[email-masked]>
Date: Tue, 1 May 2012 18:44:56 -0500

> proprietary servers which have yet to implement a MAC system.

You're missing a third use case, which is when the client wants to
purposefully run with less privilege, or when it wants more privilege
and the combined authentication of client host and user allows the
server to decide to grant this.  This is a very important use case!

In MLS terms, suppose a user has access to N compartments all at the
same level, and wants to run some application in just one compartment
at a lesser level.  If the server derives the process label from the
user's Kerberos principal name then either the user needs a principal
name for every possible process label (that could be a huge number, so
"no"), or it can't actually run processes with reduced privilege!

(The same applies to privileges [capabilities in Linux speak].)

An example of increased privilege might be where you have a policy
that allows users on trusted clients more privilege than you allow
them on other clients.  If you consider a user-land NFSv4 client...
it's got to be not trusted unless it has sufficient local privilege to
access the client's host credentials.  So the question of whether a
client is trusted is not as trivial as "all clients on our network are
trusted".  So picture a set-uid program that runs on some client as a
user but with some extra privilege, and picture that extending to
server-side resources.  The server could grant that extra privilege
*if* the server can authenticate both, the client and the user
*together*, and if policy allows it.

An MLS example might be that users on trusted clients are allowed a
higher level of access than otherwise.  But it's not desirable to just
say "oh, authenticated user on trusted client -> grant higher
clearance"!  If the client is multi-level capable then different
processes will have different clearances, and so the server MUST know
what label each process is at.

(Again, the same applies to privileges, not just labels.)

This is precisely why I put this feature into RPCSEC_GSSv3.  The
protocol allows the client to accurately describe the process'
credentials, and it allows for client host and user credentials to be
used together so that the server can take all three elements -client
host ID, user ID, and asserted privileges/labels- and decide what
actual pricileges/labels to grant.

> they already have working MAC systems.

Your e-mail address doesn't seem to imply your knowing such things.

Solaris has a multi-level capable client.  Surely Solaris engineering
should want this feature!

Linux has several labeled security systems, at least one of them a DTE
system, and one that could be described as more like MLS than DTE (I'm
thinking of SMACK).  Surely Linux developers should want this feature
then too!

Moreover, this problem came up in the context of privileges (again,
capabilities in Linux speak) in Solaris years ago, back when Least
Privilege was introduced, long before the labeled NFS came up.  This
is a real problem that wants a solution.  I designed RPCSEC_GSSv3 with
this very problem in mind.

All aspects of RPCSEC_GSSv3 save channel binding are about this.  Even
the extent to which it can replace AUTH_SYS (by allowing the client to
describe the effective group and supplementary groups of the process)
is actually about this problem.

There were two other purposes to RPCSEC_GSSv3: a cleaner channel
binding design than RPCSEC_GSSv2, and the compound authentication
feature.  The latter is necessary for properly describing process
credentials on trusted clients anyways, and it was needed
independently because otherwise there's an attack on the client.

Nico
--

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 2 May 2012 03:08:28 +0000

>server to decide to grant this.  This is a very important use case!

This is the server which only transports and stores labels, it has no
other MAC system.

You are describing a more capable server.

But I do want to thank you for further clarifying my point that the server
is able to examine more than the subject label.

>should want this feature!

The context of my statement is a server which is label aware and not MAC
aware. As such, it need not even use RPCSEC_GSSv3. I.e., what use is the
subject label if it cannot act on it?

If I consider a homogenous implementation (Solaris client talking to
Solaris server), why would Solaris engineering spend any time with the
label aware server other than as a simple debugging tool for unit testing?
And if they were interested in a heterogeneous environment, I could see
them teaching their server to map from seLinux subject labels to Trusted
Solaris labels.

Again, I do not see the label aware server being of much interest if you
already have a much more capable labeled security system available.

I do however see the advantage of the use case you propose and I can see
it being developed by vendors.

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 2 May 2012 03:16:11 +0000

>fine to revert to depending on the client's integrity.

I need to thank Nico for bringing up RPCSEC_GSSv3, in quickly glancing
back over it, it does have some text that deals with your concern in
Section 2.1.2.1:

   It is assumed that an unprivileged user-space program would not have
   access to client host credentials needed to establish a GSS-API
   security context authenticating the client to the server, therefore
   an unprivileged user-space program could not create an RPCSEC_GSSv3
   RPCSEC_GSS3_CREATE message that successfully binds a client and a
   user security context.

You can look at the draft for this at
http://www.ietf.org/id/draft-ietf-nfsv4-rpcsec-gssv3-02.txt.

I don't think this completely alleviates your concern, the key word here
is "unprivileged" and if they have root on the machine, they can easily
make the process "privileged".

---

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Wed, 2 May 2012 16:27:00 +0000

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 [[email-masked]]

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 think adding the above definitions would clear this up too.

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

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

---

From: "Haynes, Tom" <[email-masked]>
Date: Wed, 2 May 2012 22:17:44 +0000

Thanks for pointing out the use of MAC-Aware and MAC-Functional. I've
added definitions in the Introduction and cleaned up the usage in the
text. I also found an incorrect use case thanks to this!

I'm having a harder time folding in your request to discuss more on
RPCSEC_GSSv3. My issue here is that this is a requirement's document and
not a design/implementation. So we provide a set of requirements which are
met with RPCSEC_GSSv3.

1. Introduction

   (1)  Clients must be able to convey to the server the security
       attribute of the subject making the access request.  The server
       may provide a mechanism to enforce MAC policy based on the
       requesting subject's security attribute.

Š

3.3.  Security Services

    LNFS should ensure that the following security services are provided
    for all NFSv4.2 messaging.  These services may be provided by lower
    layers even if NFS has to be aware of and leverage them:

      o  Authentication

      o  Integrity

      o  Privacy

    Mechanisms and algorithms used in the provision of security services
    must be configurable, so that appropriate levels of protection may be
    flexibly specified per mandatory security policy.

    Strong mutual authentication will be required between the server and
    the client for Full Mode operation Section 3.5.1.

    MAC security labels and any related security state must always be
    protected by these security services when transferred over the
    network; as must the binding of labels and state to associated
    objects and subjects.

    LNFS should support authentication on a context granularity so that
    different contexts running on a client can use different
    cryptographic keys and facilities.

The requirements are thus a means to transport labels and to protect them.

RPCSEC_gssv3 is one means to do so. And while it happens to be the
approach we've decided to implement for NFSv4.2, it is still the means to
the requirement.

Finally, on the subject of trusting the clients, if we look at the
Introduction, it defines a MAC model as:

    MAC models base their security decisions on a system
    wide policy established by an administrator or organization which the
    users do not have the ability to override.

So by definition, your use case is not valid. :->

Having said that, I believe the definition is as flawed as can be. If we
examine a traditional MAC security model, which only applies to resources
on the client, then that approach is only as valid as the ability to keep
the root account safe. When I bring up a new Fedora installation at home,
the first thing I do is disable seLinux. I always defeat the system.

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.

---

From: "Haynes, Tom" <[email-masked]>
Date: Fri, 4 May 2012 21:35:49 +0000

>Instead of presenting the changes here, I will post a new version of the

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

---

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Thu, 10 May 2012 17:07:33 +0000

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 anything 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 interpret/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

Sent: Friday, May 04, 2012 3:35 PM

Bryce,

Thanks,
Tom

---

From: "Haynes, Tom" <[email-masked]>
Date: Thu, 10 May 2012 22:52:57 +0000

On 5/10/12 12:07 PM, "Nordgren, Bryce L -FS" <[email-masked]> wrote:

>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"?

Yes, a synonym.

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

These should be MUST:

   (2)  Servers must be able to store and retrieve the security
        attribute of exported files as requested by the client.

   (3)  Servers must provide a mechanism for notifying clients of
        attribute changes of files on the server.

   (4)  Clients and Servers must be able to negotiate Label Formats and
        provide a mechanism to translate between them as needed.

Ditto here:

3.1.  Portability & Interoperability

   LNFS must be designed with portability in mind, to facilitate
   implementations on any operating system that supports mandatory
   access controls.

   LNFS must be designed and developed to facilitate interoperability
   between different LNFS implementations.

>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 anything 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
>interpret/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?

The use case we wanted to support here was a server that had separate
portions of its namespace dedicated to different security models.

So "/smack", "/trusted_solaris", "/seLinux", etc.

Your case also applies here.

More below.

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

I don't think we can go there, that is too strong.

What I think we could state is:

If a MAC functional client is presented with a object label in a foreign
LFS, then it SHOULD only allow access to the object if it can map from the
foreign format to one it understands.

Where I am trying to go here is that we've already stated in the use case
of Section 4.5, to strongly enforce the overall security, all of the
clients SHOULD be MAC functional. So for any place in which foreign labels
are present, either be able to do a mapping or respect the security.

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

What you are describing is a policy and we are trying to leave those to
the security models. The clients already running security models already
deal with these types of scenarios.

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

Actually, the decider here for the client is not NFSv4.2, but rather the
security system. I.e., it works the same way whether it is NFSv3 or
NFSv4.2. The client mounts the server somewhere in the namespace. Somehow,
the security system decides that all objects under that mount point are
Top Secret. So even before it issues a NFS request of any version, it can
tell it cannot allow a process which is Secret to access that mount point.

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

No, it wouldn't successfully store it - the server would complain about
the label.

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

This is the case we have today - MAC functional clients talking to servers
which cannot handle objects. How can we disallow something  that systems
accommodate?

Is it something we would recommend? No, obviously we want to recommend
fully MAC functional clients and servers.

Is it something we should document the expected behavior? Yeah.

I think there are two conflicting themes in play here.

The first theme is that we are trying to set the requirements for the
transport and storage of labels, which includes a format useable by
different security models and how to do so securely. We also have to be
able to notify clients when an object label is changed. The changes to
allow this in both NFSv4.2 and RPCSEC_GSSv3 is a vast infrastructure
improvement.

And the second theme is how do the security models on the client and
server interact (which includes no such models in place). For the most
part, these are policy decisions and we are quite explicitly trying to
leave those to the security models.

We have a strong set of requirements for the first. Your question last
week about trusting the client processes without an external authorization
was spot on in this context.

For the second, we are primarily interested in documenting the models, but
not in necessarily mandating the way that the security models work. Of
prime interest here is your question above about the interaction of
different labels on a MAC aware server. This is where we deviate from
common security models and we should provide guidance.

But the remaining concerns you raise are ones that are essentially
concerned about deployment. E.g., current NFSv3 and NFSv4 clients running
MAC security models have mechanisms in place to use remote servers.
Nothing currently stops a group of seLinux clients cooperatively accessing
a server, nothing stops a group of smack enabled clients from also
accessing that same server. We also have NFSv3 and NFSv4 servers which use
proprietary methods to determine subject labels for clients.

The implementation of the security model dictates how the clients and
servers are going interact to decide policies. One scenario might see a
MAC functional server refusing to communicate with a non-MAC functional
client. While that is feasible within the confines of the changes we are
making, the reverse is not true. A MAC functional client can tell if the
server is MAC functional or not, but it has no means to tell whether the
other clients accessing it are MAC functional or not.

Such a determination can be made out of bounds, perhaps with some local
configuration rules. But again, that falls outside the scope of this
document.

---

From: "Nordgren, Bryce L -FS" <[email-masked]>
Date: Fri, 11 May 2012 16:30:42 +0000

________________________________________
From: Haynes, Tom [[email-masked]]
Sent: Thursday, May 10, 2012 4:52 PM

>subset of MAC labels attached to "security objects"?

Yes, a synonym.
<<<<<

OK

....

<<<<<

I see. But the above statement allows the MAC-functional client to discard the security info for any reason. Also, non-MAC-aware clients may connect to the "protected" directory, completely bypassing the MAC infrastructure. The number and type of clients attempting a connection to a server is in general beyond the administrator's control. My concern here is that there is no way for the admin to set policy at all, since it can be bypassed at will by anyone who feels like it.

Perhaps there should be a requirement that MAC aware servers MUST provide a control for "strong(er) security". When enabled, the MAC-aware server with strong(er) security disallows access to non-empty-label objects if the client is: a] non-MAC-functional; or b] a MAC-functional client which cannot translate the label into something it understands. The labeling protocol MUST provide a means for MAC aware servers to communicate this setting with clients (which MUST communicate the setting to the security model running on the client, if one is running).

<<<<<

Ahh. OK.

<<<<<

The server in 4.7.2.2 is non-MAC-aware. The protocol is therefore "regular NFS (no labels)". The server doesn't even know the file has a label and cannot object.

<<<<<

Isn't this the situation that Labeled NFS is supposed to address? If a sysadmin wants this behaviour, they can turn Labeled NFS off, right? A MAC-aware server is supposed to be the thing which is capable of stopping the above mixing unless a translation is in place. Likewise with the above: a MAC-functional client must always respect the security label of the object or deny access because it can't interpret it. If a sysadmin wants to ignore the security label, they can turn labeled NFS off for the client and connect as non-MAC-aware. This advertises to the server whether the label will be respected or not. This allows you to make stronger statements about what MAC-functional clients/servers are required to do without sacrificing functionality.

<<<<<

It also has no means of telling the security model running on the client whether:

a] it is mac functional or mac aware
b] the server it is connecting to is non-mac-aware, mac-aware, mac-functional.

This communication with the security model should probably be a requirement. And if the security model is supposed to be "in charge", then Labeled NFS capable clients should also offer controls to the security model, so the security model can instruct the client to refuse to connect to a non-MAC-functional server.

---

From: "Haynes, Tom" <[email-masked]>
Date: Fri, 11 May 2012 15:20:47 -0700

No, it cannot bypass security at all. If the client gets a label with a foreign LFS, it
SHOULD do either of

1) Translate it if it understands the foreign LFS and then decide what to do with it.

2) Throw it away because it is respecting the authority of the foreign LFS.

In terms 

> The server in 4.7.2.2 is non-MAC-aware. The protocol is therefore "regular NFS (no labels)". The server doesn't even know the file has a label and cannot object.

But it is still NFSv4.2, which means it would understand that it does not support
sec_label. Further, it will be quite happy to inform the client that it does
not understand/support sec_label and thus the client should not send it again.

File attributes are part of the base NFSv4 standard and have well understood
behavior when the server does not support one.

> a] it is mac functional or mac aware

That is something the can be defined as an API call on the client. And is out of
our scope.

> b] the server it is connecting to is non-mac-aware, mac-aware, mac-functional.

The client can infer if the server is non-MAC aware by storing an object label and
then asking for it back. If it is not returned, then the server is non-MAC aware/functional.

Further, from the NFSv4.2 draft:

7.5.  Discovery of Server LNFS Support

   The server can easily determine that a client supports LNFS when it
   queries for the FATTR4_SEC_LABEL label for an object.  Note that it
   cannot assume that the presence of RPCSEC_GSSv3 indicates LNFS
   support.  The client might need to discover which LFS the server
   supports.

   A server which supports LNFS MUST allow a client with any subject
   label to retrieve the FATTR4_SEC_LABEL attribute for the root
   filehandle, ROOTFH.  The following compound MUST always succeed as
   far as a MAC label check is concerned:

        PUTROOTFH, GETATTR {FATTR4_SEC_LABEL}

   Note that the server might have imposed a security flavor on the root
   that precludes such access.  I.e., if the server requires kerberized
   access and the client presents a compound with AUTH_SYS, then the
   server is allowed to return NFS4ERR_WRONGSEC in this case.  But if
   the client presents a correct security flavor, then the server MUST
   return the FATTR4_SEC_LABEL attribute for the supported LFS.

Further, as the intent all along has been that MAC-aware is a special LFS variant,
this compound will indeed inform the client that the server is either MAC-aware or
MAC-functional.

A server is either non-MAC functional or MAC functional. A limited variant of a
MAC functional server is a LFS of value X (i.e., we haven't registered that value
yet, there is debate about whether it is 0 or something else).

A server MUST only return that LFS in the label for the above compound if
it is MAC aware. If it is MAC functional, it MUST not return that value.

So a client and server can tell the functinality of the other with a single compound.

> This communication with the security model should probably be a requirement. And if the security model is supposed to be "in charge", then Labeled NFS capable clients should also offer controls to…

This is policy and we are not dictating policy to the security models.

Some simple ways I can see to do this:

1) Say a security model exists which will connect to a non-MAC-functional
system and it is LFS F. An organization decides it needs a security model
which will refuse to connect to a non-MAC-functional system. It creates
a new LFS of F' and registers it with IANA. A system with LFS F' can then
refuse to communicate with any system which does not use LFS F'.

2) Before connecting to a system, a machine will consult an external
server to determine if that system is MAC-functional and will only
connect to other MAC functional systems.

And we actually do state as a requirement:

3.5.1.  Full Mode

   The server and the client have mutually recognized MAC functionality
   enabled, and full LNFS functionality is extended over the network
   between both client and server.

-- 
[email-masked], ex-cfb

---

From: "Haynes, Tom" <[email-masked]>
Date: Fri, 11 May 2012 22:53:52 +0000

On 5/11/12 11:30 AM, "Nordgren, Bryce L -FS" <[email-masked]> wrote:

>
>
>Isn't this the situation that Labeled NFS is supposed to address? If a
>sysadmin wants this behaviour, they can turn Labeled NFS off, right? A
>MAC-aware server is supposed to be the thing which is capable of stopping
>the above mixing unless a translation is in place. Likewise with the
>above: a MAC-functional client must always respect the security label of
>the object or deny access because it can't interpret it. If a sysadmin
>wants to ignore the security label, they can turn labeled NFS off for the
>client and connect as non-MAC-aware. This advertises to the server
>whether the label will be respected or not. This allows you to make
>stronger statements about what MAC-functional clients/servers are
>required to do without sacrificing functionality.

In rereading the Requirements, we already call out what must happen here
in Section 3.4:

      If a system receives any security label or security state tagged
with an
      LFS it does not recognize or cannot interpret, it must reject that
label
      or state.