RFC 7204

Requirements for Labeled NFS

📅 published April 2014, from ietf

Requirements for Labeled NFS 💖

Okay bestie, this is RFC 7204 🎀 It's titled "Requirements for Labeled NFS" and it's by T. Haynes from NetApp. It's an Informational doc, so it's published for information and isn't a Standards Track spec. It's dated April 2014, with ISSN 2070-1721. Its title block doesn't list any RFCs that it obsoletes or updates, so it's a totally standalone vibe 🧚

Abstract ✨

Okay so this memo lays out high-level requirements for bringing flexible Mandatory Access Control (MAC) functionality into the Network File System (NFS) version 4.2 (NFSv4.2). It talks about the level of protection that should be provided over protocol components, plus the basic structure of the proposed system. The point here isn't to present the protocol changes. It's to describe the environment they live in 🌸

Status of This Memo 🦋

This document is not an Internet Standards Track specification. It's published for informational purposes, so no pressure 🙈

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, and it's had public review and been approved for publication by the Internet Engineering Steering Group (IESG). Not every document the IESG approves is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 for the deets.

Info about the current status of this document, any errata, and how to give feedback on it is at http://www.rfc-editor.org/info/rfc7204.

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 🫶

Table of Contents 🧾

1. Introduction ....................................................3
2. Definitions .....................................................3
   2.1. Requirements Language ......................................4
3. Requirements ....................................................4
   3.1. General ....................................................4
   3.2. Security Services ..........................................5
   3.3. Label Encoding, Label Format Specifiers, and Label
        Checking Authorities .......................................5
   3.4. Labeling ...................................................6
        3.4.1. Client Labeling .....................................6
        3.4.2. Server Labeling .....................................7
   3.5. Policy Enforcement .........................................7
        3.5.1. Client Enforcement ..................................7
        3.5.2. Server Enforcement ..................................8
   3.6. Namespace Access ...........................................8
   3.7. Upgrading Existing Server ..................................9
4. Modes of Operation ..............................................9
   4.1. Full Mode ..................................................9
   4.2. Limited Server Mode .......................................10
   4.3. Guest Mode ................................................10
5. Use Cases ......................................................11
   5.1. Full MAC Labeling Support for Remotely Mounted
        File Systems ..............................................11
   5.2. MAC Labeling of Virtual Machine Images Stored on
        the Network ...............................................11
   5.3. Simple Security Label Storage .............................12
   5.4. Diskless Linux ............................................12
   5.5. Multi-Level Security ......................................13
        5.5.1. Full Mode - MAC-Functional Client and Server .......13
        5.5.2. MAC-Functional Client ..............................14
        5.5.3. MAC-Functional Server ..............................15
6. Security Considerations ........................................15
   6.1. Trust Needed for a Community ..............................15
   6.2. Guest Mode ................................................15
   6.3. MAC-Functional Client Configuration .......................16
7. References .....................................................16
   7.1. Normative References ......................................16
   7.2. Informative References ....................................16
Appendix A. Acknowledgments .......................................18

1. Introduction 🌈

Mandatory Access Control (MAC) systems (as defined in [RFC4949]) are totally mainstream now in modern operating systems like Linux, FreeBSD, and Solaris 💅 MAC systems attach security attributes to subjects (processes) and objects inside a system. Those attributes get used alongside other information in the system to make access control decisions.

Access control models like Unix permissions or Access Control Lists (ACLs) are usually called Discretionary Access Control (DAC) models. These systems base their access decisions on user identity and resource ownership. MAC models are different. They base their access control decisions on the label on the subject (usually a process) and the object it wants to access. Those labels may contain user identity information, but they usually contain more than that ✨ In DAC systems, users are free to set the access rules for resources they own. MAC models base their security decisions on a system-wide policy set by an administrator or organization, and users can't override it. DAC systems offer some protection against unauthorized users running malicious software. However, even an authorized user can run malicious or flawed software, and those programs run with the full permissions of the user running them 😭 On the flip side, MAC models can confine malicious or flawed software, and they usually work at a finer granularity than their DAC counterparts 🔥

Besides describing the requirements, this document records the functional requirements that the preexisting security models impose on the client. This document may help people outside the NFS community understand those issues 🧚

2. Definitions 🎀

Foreign Label: a label in a format other than the format that a MAC implementation uses for encoding.

Label Format Specifier (LFS): an identifier the client uses to establish the syntactic format of the security label and the semantic meaning of its components.

MAC-Aware: a server that can transmit and store object labels.

MAC-Functional: a client or server that is Labeled NFS enabled. Such a system can interpret labels and apply policies based on the security system.

Multi-Level Security (MLS): a traditional model where objects are given a sensitivity level (Unclassified, Secret, Top Secret, etc.) and a category set [RH_MLS].

Object: a passive resource within the system that we wish to protect. Objects can be entities such as files, directories, pipes, sockets, and many other system resources relevant to the protection of the system state.

Policy Identifier (PI): an optional part of the definition of a Label Format Specifier. The PI lets clients and servers identify specific security policies.

Subject: an active entity, usually a process, that is requesting access to an object.

2.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

3. Requirements 💖

The following initial requirements were gathered from users and developers, and from earlier development efforts in this area, like the Distributed Trusted Operating System [DTOS] and the NSA's experimental NFSv3 enhancements [SENFSv3].

3.1. General

A mechanism is required to provide security attribute information to NFSv4 clients and servers. This mechanism has the following requirements:

  1. Clients MUST be able to convey to the server the client's privileges, i.e., the subject, for making the access request. The server may provide a mechanism to enforce MAC policy based on the requesting client's privileges.
  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.

3.2. Security Services 🔐

Labeled NFS, or the underlying system it runs on, MUST provide the following security services for all NFSv4.2 messaging:

  • Authentication
  • Integrity
  • Privacy

Mechanisms and algorithms used to provide security services MUST be configurable, so that appropriate levels of protection may be flexibly specified per mandatory security policy.

Strong mutual authentication is required between the server and the client for Full Mode operation (Section 4.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.

Labeled NFS SHOULD support authentication on a context granularity, so that different contexts running on a client can use different cryptographic keys and facilities.

Next up is Section 3.3, where the label encoding gets real 👀 More soon, bestie 🦋

3.3. Label Encoding, Label Format Specifiers, and Label Checking Authorities ✨

Okay bestie, labels that travel over the network MUST be encoded in a complete and unambiguous way, but MAC implementations still get to be flexible 💅. So every label MUST be a format-specific component bound together with a Label Format Specifier (LFS) 🏷️. The LFS is the part that tells you how the opaque component is structured and what it means. The opaque component is the actual security label, and it's what the MAC models interpret 🔍.

MAC models make access decisions based on security attribute privileges bound to subjects and objects, respectively 🦋. Within a given MAC model, every system needs semantically coherent labeling. A security label MUST always mean exactly the same thing on every system 💜. That might not be necessary for simple MAC models, but it's recommended that most Label Formats that get an LFS build semantically coherent labeling right into their Label Format 🎀.

Labeled NFS SHOULD define an initial negotiation scheme whose main goals are simplicity and completeness 🌸. This keeps deployment practical so nobody gets dragged down by complicated, overgeneralized global schemes 🙈. Future extensibility SHOULD also be taken into consideration ⭐.

Labeled NFS MUST provide a way for servers and clients to identify their LFSs for authorization, security service selection, and security label interpretation 🔥. Labeled NFS MUST also provide a way for servers and clients to identify their mode of operation (see Section 4) 👑.

A negotiation scheme SHOULD be provided so systems from different Label Formats can agree on how they'll interpret or translate each other's foreign labels 🧚. Multiple concurrent agreements may be current between a server and a client, which is very main character of them 💅.

All security labels and related security state transferred across the network MUST be tagged with a valid LFS 🫶. If the LFS supported on a system changes, the system SHOULD renegotiate agreements to reflect those changes 🌈. And if a system receives any security label or security state tagged with an LFS it doesn't recognize or can't interpret, it MUST reject that label or state 💀.

NFSv4.2 has features that may cause a client to cross an LFS boundary while it's accessing what looks like a single file system 🦋. If the client and the server both support LFS negotiation, the server SHOULD negotiate a new, concurrent agreement with the client, acting on behalf of the externally located source of the files 🍓.

3.4. Labeling 🎀

Implementations MUST validate security labels supplied over the network to make sure they fall within a set of labels permitted from a specific peer. If they don't, they MUST reject them 🙅‍♀️. Note that a system may permit a different set of labels to be accepted from each peer 🌸.

3.4.1. Client Labeling 💖

At the client, labeling semantics for NFS mounted file systems MUST remain consistent with those for locally mounted file systems 🦋. In particular, user-level labeling operations local to the client MUST be enacted locally via existing APIs, so applications and libraries stay compatible and consistent ✨.

Note that this does not imply any specific mechanism for conveying labels over the network 🫶.

When the client creates a new object, it calculates the label for that object based on its policy 🔍. Once that's done, it sends the request to the server, and the server has the ability to deny creating the object with that label based on the server's policy 💅. When creating the file, the server MUST ensure the label is bound to the object before the object becomes visible to the rest of the system 🔒. This makes sure any access control or further labeling decisions are correct for the object 👑.

3.4.2. Server Labeling 🌈

The server MUST provide the capability for clients to retrieve security labels on all exported file system objects where possible 🧚. This includes cases where only in-core and/or read-only security labels are available at the server for any of its exported file systems 🌸.

The server MUST honor the ability for a client to specify the label of an object on creation 💜. If the server is MAC enabled, it may choose to reject the label specified by the client because of restrictions in the server policy 🙈. The server SHOULD NOT attempt to find a suitable label for an object when its labeling rules differ 💀. The server is allowed to translate the label, but it MUST NOT change the semantic meaning of the label 🎀.

3.5. Policy Enforcement 🔥

The MAC-Functional client decides whether a process request gets sent to the remote server 🦋. After a successful response from the server, it must use its own policies on the object's security labels to decide whether the process can get access ✨. The client SHOULD NOT need to care about whether the server is a Limited Server or fully MAC-Functional 🫶.

3.5.1. Client Enforcement 💅

The client MUST apply its own policy to remotely located objects, using the security labels for those objects it got from the server 👑. It MUST be possible to configure the maximum length of time a client may cache state about remote labels before revalidating that state with the server ⏳.

If the server's policy changes, the client MUST flush all object state back to the server 🌈. The server MUST ensure that any flushed state it receives is consistent with current policy before committing it to stable storage 🔒.

Any local security state associated with cached or delegated objects MUST also be flushed back to the server whenever any other state of those objects is required to be flushed back 🍓.

What this means is that if the client holds a delegation on an object, it enforces policy on local changes based on the object label it got from the server 🧚. When it tries to commit those changes to the server, it SHOULD be prepared for the server to reject them based on the server's policies 💀.

3.5.2. Server Enforcement 🦋

A MAC-Functional server MUST enforce its security policy over all exported objects, for operations that originate both locally and remotely 🔥.

Requests from authenticated clients MUST be processed using security labels and credentials supplied by the client, as if they came from a local source 💖.

Just like with labeling, the system MUST also take into account any other volatile client security state, such as a change in process security context via dynamic transition 🌸. Access decisions SHOULD also be based on the current client security label accessing the object, rather than the security label that opened it, if those differ 👑.

The server SHOULD recall delegation of an object if the object's security label changes 💜.

3.6. Namespace Access 🧚

The server SHOULD provide a means to authorize selective access to the exported file system namespace, based on client credentials and according to security policy 🌈.

This is a common requirement of MLS-enabled systems, which often need to present selective views of namespaces based on the clearances of the subjects 🎀.

3.7. Upgrading Existing Server 🫶

Note that under the MAC model, all objects MUST have labels 🔒. So if an existing server gets upgraded to include Labeled NFS support, it's the responsibility of the security system to define the behavior for existing objects 💅.

4. Modes of Operation 👑

In a Labeled NFS client and server interaction, we can describe three modes of operation 🦋:

  1. Full
  2. Limited Server
  3. Guest

These modes come from how much MAC functionality the clients and servers have 🌸. Clients can be non-MAC-Functional or MAC-Functional. Servers can be non-MAC-Functional, MAC-Aware, or MAC-Functional 🧚.

A MAC-Functional client MUST be able to determine the level of MAC functionality in the server. Likewise, a MAC-Functional server MUST be able to determine whether or not a client is MAC-Functional. As discussed in Section 3.3, the protocol MUST provide for the client and server to make those determinations 🔍.

4.1. Full Mode 💖

In Full Mode, the server and the client have mutually recognized MAC functionality enabled, and full Labeled NFS functionality is extended over the network between both of them ✨.

Here's an example of an operation in Full Mode 🎀. On the initial lookup, the client requests access to an object on the server, and it sends its process security context over to the server 💌. The server checks all the relevant policies to determine whether that process context from that client is allowed to access the resource 🔒. Once that succeeds, the object, along with its associated security information, is released to the client 🫶. Then, when the client receives the object, it determines whether its policies allow the process running on the client to access it 👑.

On later operations, when the client already has a handle for the file, the order of enforcement flips 🙃. Since the client already has the security context, it can make an access decision against its own policy first 🌈. This lets the client avoid sending requests to the server that it knows will fail, no matter what the server's policy is 💅. If the client passes its policy checks, it sends the request to the server, where the client's process context is used to decide whether the server will release that resource to the client 🍓. If both checks pass, the client gets the resource and everything succeeds 🥳.

If the client doesn't trust the server, it may opt to use an alternate labeling mechanism, regardless of the server's ability to return security information 🦋.

4.2. Limited Server Mode 🌸

In Limited Server Mode, the server is MAC-Aware and the clients are MAC-Functional 🧚. The server can store and transmit labels, but it cannot enforce them 💜. The server MUST inform clients when an object label changes for a file the client has open 🔥.

In this mode, the server may not be aware of the format of any of its object labels 🙈. In fact, it may service several different security models at the same time 🌈. A client MUST process foreign labels as discussed in Section 3.3 ✨. Just like with Guest Mode, this mode's level of trust can get degraded if non-MAC-Functional clients have access to the server 💀.

4.3. Guest Mode 🎀

In Guest Mode, only one of the server or client is MAC-Functional enabled 🫶.

If only the server is MAC-Functional, the server enforces its policy and may selectively provide standard NFS services to clients. It does this based on their authentication credentials and/or associated network attributes (e.g., IP address, network interface), according to security policy 🔒. The level of trust and access extended to a client in this mode is configuration-specific 👑.

If only the client is MAC-Functional, the client MUST operate as a standard NFSv4.2 client (see [NFSv4_2]) and SHOULD selectively provide processes access to servers based on the security attributes of the local process and the network attributes of the server, according to policy 💅. The client may also override the default labeling of the remote file system based on these security attributes or other labeling methods, such as mount point labeling 🦋.

In other words, Guest Mode is standard NFSv4.2 over the wire, with the MAC-Functional system mapping the non-MAC-Functional system's processes or objects to security labels based on other characteristics, so it can keep its MAC guarantees intact 🌈✨

5. Use Cases ✨

okay so MAC labeling is basically meant to let NFSv4.2 fit into all kinds of site-configurable security setups 🔐 The LFS and opaque data scheme gives it the flexibility to handle these different implementations. This section is a tour of some examples of how NFSv4.2 could be deployed to meet existing needs. It's not an exhaustive list, bestie 💅

5.1. Full MAC Labeling Support for Remotely Mounted File Systems

here we assume a local network where the servers and clients are all under common administrative control 🏠 Every system has the same MAC implementation and semantically identical MAC security labels for objects. The labels mean the same thing on different systems, even if the policies on each system differ a bit. Clients can apply fine-grained MAC policy to objects accessed over NFS mounts, which improves the overall consistency of MAC policy application in this environment ✨

Picture user home directories that are remotely mounted, with fine-grained MAC policy protecting things like private user data from being read by malicious web scripts running in the user's browser 👀 With Labeled NFS, fine-grained MAC labeling of the user's files lets that MAC policy get implemented and gives the protection it's meant to 🛡️

5.2. MAC Labeling of Virtual Machine Images Stored on the Network

virtualization is totally mainstream now 💻 and MAC security policy needs to be able to protect virtualized resources too. A common setup stores virtualized guest file systems on a networked server, and guests mount them remotely when they spin up. So the local guest kernel needs to be able to access fine-grained MAC labels on that remotely mounted file system, so its MAC policy can actually be applied 🫶

5.3. Simple Security Label Storage

this one is a mixed, loosely administered network where nodes might run a bunch of different operating systems with different security mechanisms and policies 🌈 Network file servers just need to be able to store and retrieve MAC security labels for the clients that use them. Labeled NFS would be implemented here only to carry MAC security labels across the network. It should be noted that overall security can't be as strongly enforced as when the server is enforcing too 😬 The whole point of this scheme is letting MAC-capable clients keep their MAC security policy turned on, instead of maybe turning it off entirely 💜

5.4. Diskless Linux

a bunch of popular OS distributions depend on a Mandatory Access Control (MAC) model to implement a kernel-enforced security policy 🐧 Usually these models give particular roles to individual processes, which limit or permit certain operations on a set of files, directories, sockets, or other objects. The enforcing of the policy is typically up to the diskless NFS client itself, but the file system objects in these models will typically carry MAC labels that define policy on access. These policies might describe privilege transitions that you can't replicate with standard NFS ACL-based models 🔑

For example, on a SYSV-compatible system (see [SYSV]), if the 'init' process spawns a process that tries to start the 'NetworkManager' executable, there may be a policy that sets up a role transition if the 'init' process and 'NetworkManager' file labels match a particular rule. Without that role transition, the process might not have enough privileges to do its main job of configuring network interfaces 🌐

In setups like this, a lot of the policy targets (like sockets or privileged system calls) are entirely local to the client. So using RPCSEC_GSSv3 ([RPC_SEC]) for enforcing compliance at the server level is of limited value 🤷 But being able to permanently label files and have the client read those labels back is crucial for enforcing that policy 💖

5.5. Multi-Level Security

in an MLS system, objects usually get a sensitivity level and a set of compartments 👑 The sensitivity levels are ordered from lowest to highest classification level. Read access to an object is allowed when the subject's sensitivity level "dominates" the object it wants to access. That means the subject's sensitivity level is higher than the object's, and its set of compartments is a superset of the object's compartments 🧚

The rest of this section will only use sensitivity levels. The general example is a client that wants to list the contents of a directory. The system defines the levels as Unclassified (U), Secret (S), and Top Secret (TS). The directory being searched is labeled Top Secret, so reading it is only granted if the requesting subject is also labeled Top Secret 🔒

5.5.1. Full Mode - MAC-Functional Client and Server

in the first part, a process on the client is running at Secret. It issues a readdir() system call, which enters the kernel. Before translating readdir() into a request to the NFSv4.2 server, the host operating system consults the MAC module to see if the operation is allowed. Since the process is at Secret and the directory is labeled Top Secret, the MAC module denies the request and an error code goes back to user space 🙅

Now the second case: the process is running at Top Secret instead. The sensitivity of the process is equal to or greater than that of the directory, so the MAC module allows the request. Now readdir() gets translated into the necessary NFSv4.2 call to the server. For the remote procedure call (RPC) request, the client uses the proper credential to assert to the server that the process is running at Top Secret 🎀

When the server gets the request, it extracts the security label from the RPC session and retrieves the label on the directory. The server then checks with its MAC module to see if a Top Secret process is allowed to read the contents of the Top Secret directory. Since the policy allows it, the server returns the appropriate information back to the client ✅

In this example the policy on the client and server is the same. If they were running different policies, a translation of the labels might be needed. In that case, it could be possible for a check to pass on the client and fail on the server. The server may consider additional information when making its policy decisions. For example, the server could determine that a certain subnet is only cleared for data up to Secret classification. If that constraint was in place for the example above, the client would still succeed, but the server would fail, since the client is asserting a label that it isn't able to use (Top Secret on a Secret network) 😭

5.5.2. MAC-Functional Client

in these scenarios the server is either non-MAC-Aware or MAC-Aware. What the client does depends on whether it's configured to treat the MAC-Aware server the same way as a non-MAC-Aware one. That is, does it use the approach presented in Section 4.3, or does it allow the MAC-Aware server to return labels? 🤔

With a client that is MAC-Functional using the example in the previous section, the result should be the same. The one difference is that all decisions are made on the client 💅

5.5.2.1. MAC-Aware Server

a process on the client labeled Secret wants to access a directory labeled Top Secret on the server. This is denied, since Secret does not dominate Top Secret. Note that there will be NFSv4.2 operations issued that return an object label for the client to process 💫

Note that in this scenario, all of the clients must be MAC-Functional. A single client that does not do its access control checks would violate the model 🚨

5.5.2.2. Non-MAC-Aware Server

a process on the client labeled Secret wants to access a directory that the client's policies label as Top Secret on the server. This is denied, since Secret does not dominate Top Secret. Note that there will not be NFSv4.2 operations issued. If the process had a Top Secret label instead of Secret, the client would issue NFSv4.2 operations to access the directory on the server 🙌

5.5.3. MAC-Functional Server

with a MAC-Functional server and a client that isn't, the client behaves as if it were in a normal NFSv4.2 environment. Since the process on the client does not provide a security attribute, the server must define a mechanism for labeling all requests from a client. Assume the server is using the same criteria as in the first example. The server sees the request as coming from a subnet that is a Secret network. The server determines that all clients on that subnet will have their requests labeled Secret. Since the directory on the server is labeled Top Secret and Secret does not dominate Top Secret, the server would fail the request with NFS4ERR_ACCESS ❌

6. Security Considerations 🔐

6.1. Trust Needed for a Community

Labeled NFS is a transport mechanism for labels, a storage requirement for labels, and a definition of how to interpret labels. It defines the responsibilities of the client and the server in the various permutations of being MAC-Functional. It does not, however, dictate in any manner whether assumptions can be made about other entities in the relationship. For example, it does not define whether a MAC-Functional client can demand that a MAC-Aware server only accept requests from other MAC-Functional clients. That is a policy based on a MAC model, and this document does not impose policies on systems 🫶

As the requirement is a policy, it can be met with the use of a MAC model. Let L be an LFS that implements the Limited Server mode, i.e., a MAC-Aware server connected to MAC-Functional clients. Then a new LFS, L', can be created that has the additional policy that the MAC-Aware server MUST NOT accept any requests from a non-MAC-Functional client 🧠

6.2. Guest Mode

When either the client or server is operating in Guest Mode, it is important to realize that one side is not enforcing MAC protections. Alternate methods are being used to handle the lack of MAC support, and care should be taken to identify and mitigate threats from possible tampering outside of these methods 🚨

6.3. MAC-Functional Client Configuration 🔐

okay so bestie, a MAC model is basically an access control decision made on a system where normal users can't override the policies (see Section 1) 🙅‍♀️. now here's the tea: if the process labels are made only on the client, and a sneaky user has enough access on that client, the Labeled NFS model is compromised 💀. and ngl this is no different from two things we already have:

  • current setups where the server uses policies to decide the object label for requests from the client, or
  • local decisions the client makes through the MAC security system 🧠

so either the server has to explicitly trust the client (like in [SENFSv3]) 🤝, or the MAC model should enforce that users can't override policies, maybe with help from an externally managed source 🏰. choose your fighter, periodt 💅

once the labels leave the client, they can be protected by the transport mechanism described in Section 3.2 🦋 so they're not just floating around unprotected ✨

7. References 📚

7.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

7.2. Informative References

[DTOS]     Smalley, S., "The Distributed Trusted Operating System
           (DTOS) Home Page", December 2000, <http://www.cs.utah.edu/
           flux/fluke/html/dtos/HTML/dtos.html>.

[NFSv4_2]  Haynes, T., "NFS Version 4 Minor Version 2", Work in
           Progress, February 2014.

[RFC4949]  Shirey, R., "Internet Security Glossary, Version 2", RFC
           4949, August 2007.

[RH_MLS]   "Multi-Level Security (MLS)", "Deployment, configuration
           and administration of Red Hat Enterprise Linux 5, Edition
           10", Section 49.6, 2014, <http://docs.redhat.com/docs/
           en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/
           sec-mls-ov.html>.

[RPC_SEC]  Adamson, W. and N. Williams, "Remote Procedure Call (RPC)
           Security Version 3", Work in Progress, February 2014.

[SENFSv3]  Carter, J., "Implementing SELinux Support for NFS",
           <http://www.nsa.gov/research/_files/selinux/papers/
           nfsv3.pdf>.

[SYSV]     AT&T, "System V Interface Definition (SVID)", Third
           Edition, Addison-Wesley, Reading, MA, 1989.

Appendix A. Acknowledgments 🎀

okay the thank-you list is my favorite part 🥹 David Quigley was the early energy that got the entire Labeled NFS effort going 🔥

James Morris, Jarrett Lu, and Stephen Smalley were all key contributors, both to the early versions of this document and to tons of conference calls 📞🌸

Kathleen Moriarty provided use cases for earlier versions of the document 💜

Dan Walsh provided use cases for Secure Virtualization, Sandboxing, and NFS homedir labeling to handle process separation 🧚

Trond Myklebust provided use cases for secure diskless NFS clients 🍓

Nico Williams and Bryce Nordgren both challenged assumptions during the review processes, and we love a good challenger 👑✨

Author's Address 🦋

Thomas Haynes
NetApp
495 East Java Dr.
Sunnyvale, CA  94089
USA

Phone: +1 408 215 1519
EMail: tdh@excfb.com
📦 where this page comes from