summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7204.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7204.txt')
-rw-r--r--doc/rfc/rfc7204.txt1011
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc7204.txt b/doc/rfc/rfc7204.txt
new file mode 100644
index 0000000..c49f0d4
--- /dev/null
+++ b/doc/rfc/rfc7204.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) T. Haynes
+Request for Comments: 7204 NetApp
+Category: Informational April 2014
+ISSN: 2070-1721
+
+
+ Requirements for Labeled NFS
+
+Abstract
+
+ This memo outlines high-level requirements for the integration of
+ flexible Mandatory Access Control (MAC) functionality into the
+ Network File System (NFS) version 4.2 (NFSv4.2). It describes the
+ level of protections that should be provided over protocol components
+ and the basic structure of the proposed system. The intent here is
+ not to present the protocol changes but to describe the environment
+ in which they reside.
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7204.
+
+Copyright Notice
+
+ 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, as 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 are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+Haynes Informational [Page 1]
+
+RFC 7204 ReqLabeledNFS April 2014
+
+
+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
+
+
+
+
+
+
+
+
+
+
+Haynes Informational [Page 2]
+
+RFC 7204 ReqLabeledNFS April 2014
+
+
+1. Introduction
+
+ Mandatory Access Control (MAC) systems (as defined in [RFC4949]) have
+ been mainstreamed in modern operating systems such as Linux, FreeBSD,
+ and Solaris. MAC systems bind security attributes to subjects
+ (processes) and objects within a system. These attributes are used
+ with other information in the system to make access control
+ decisions.
+
+ Access control models such as Unix permissions or Access Control
+ Lists (ACLs) are commonly referred to as Discretionary Access Control
+ (DAC) models. These systems base their access decisions on user
+ identity and resource ownership. In contrast, MAC models base their
+ access control decisions on the label on the subject (usually a
+ process) and the object it wishes to access. These labels may
+ contain user identity information but usually contain additional
+ information. In DAC systems, users are free to specify the access
+ rules for resources that they own. MAC models base their security
+ decisions on a system-wide policy established by an administrator or
+ organization that the users do not have the ability to override. DAC
+ systems offer some protection against unauthorized users running
+ malicious software. However, even an authorized user can execute
+ malicious or flawed software with those programs running with the
+ full permissions of the user executing it. Inversely, MAC models can
+ confine malicious or flawed software and usually act at a finer
+ granularity than their DAC counterparts.
+
+ Besides describing the requirements, this document records the
+ functional requirements for the client imposed by the preexisting
+ security models on the client. This document may help those 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 used by the client 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.
+
+
+
+
+
+Haynes Informational [Page 3]
+
+RFC 7204 ReqLabeledNFS April 2014
+
+
+ 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 allows clients and servers to
+ 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 have been gathered from users and
+ developers, and from previous development efforts in this area such
+ as 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.
+
+
+
+Haynes Informational [Page 4]
+
+RFC 7204 ReqLabeledNFS April 2014
+
+
+3.2. Security Services
+
+ Labeled NFS or the underlying system on which the Labeled NFS
+ operates MUST provide the following security services for all NFSv4.2
+ messaging:
+
+ 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 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.
+
+3.3. Label Encoding, Label Format Specifiers, and Label Checking
+ Authorities
+
+ Encoding of MAC labels and attributes passed over the network MUST be
+ specified in a complete and unambiguous manner while maintaining the
+ flexibility of MAC implementations. To accomplish this, the labels
+ MUST consist of a format-specific component bound with a Label Format
+ Specifier (LFS). The LFS component provides a mechanism for
+ identifying the structure and semantics of the opaque component.
+ Meanwhile, the opaque component is the security label that will be
+ interpreted by the MAC models.
+
+ MAC models base access decisions on security attribute privileges
+ bound to subjects and objects, respectively. With a given MAC model,
+ all systems have semantically coherent labeling -- a security label
+ MUST always mean exactly the same thing on every system. While this
+ may not be necessary for simple MAC models, it is recommended that
+ most Label Formats assigned an LFS incorporate semantically coherent
+ labeling into their Label Format.
+
+
+
+
+Haynes Informational [Page 5]
+
+RFC 7204 ReqLabeledNFS April 2014
+
+
+ Labeled NFS SHOULD define an initial negotiation scheme with the
+ primary aims of simplicity and completeness. This is to facilitate
+ practical deployment of systems without being weighed down by complex
+ and overgeneralized global schemes. Future extensibility SHOULD also
+ be taken into consideration.
+
+ Labeled NFS MUST provide a means for servers and clients to identify
+ their LFSs for the purposes of authorization, security service
+ selection, and security label interpretation.
+
+ Labeled NFS MUST provide a means for servers and clients to identify
+ their mode of operation (see Section 4).
+
+ A negotiation scheme SHOULD be provided, allowing systems from
+ different Label Formats to agree on how they will interpret or
+ translate each other's foreign labels. Multiple concurrent
+ agreements may be current between a server and a client.
+
+ 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 these changes.
+
+ 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.
+
+ NFSv4.2 includes features that may cause a client to cross an LFS
+ boundary when accessing what appears to be a single file system. If
+ LFS negotiation is supported by the client and the server, 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 ensure that they are within a set of labels permitted from
+ a specific peer and, if not, 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, to ensure compatibility and
+ consistency for applications and libraries.
+
+
+
+Haynes Informational [Page 6]
+
+RFC 7204 ReqLabeledNFS April 2014
+
+
+ Note that this does not imply any specific mechanism for conveying
+ labels over the network.
+
+ When an object is newly created by the client, it will calculate the
+ label for the object based on its policy. Once that is done, it will
+ send the request to the server, which has the ability to deny the
+ creation of the object with that label based on the server's policy.
+ In creating the file, the server MUST ensure that the label is bound
+ to the object before the object becomes visible to the rest of the
+ system. This ensures that 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, due to
+ restrictions in the server policy. The server SHOULD NOT attempt to
+ find a suitable label for an object in the event of different
+ labeling rules on its end. The server is allowed to translate the
+ label but MUST NOT change the semantic meaning of the label.
+
+3.5. Policy Enforcement
+
+ The MAC-Functional client determines if a process request is sent to
+ the remote server. Upon a successful response from the server, it
+ must use its own policies on the object's security labels to
+ determine if the process can be given access. The client SHOULD NOT
+ need to be cognizant of whether the server is a Limited Server or is
+ fully MAC-Functional.
+
+3.5.1. Client Enforcement
+
+ The client MUST apply its own policy to remotely located objects,
+ using security labels for the objects obtained from the server. It
+ MUST be possible to configure the maximum length of time a client may
+ cache state regarding remote labels before revalidating that state
+ with the server.
+
+
+
+
+
+
+
+Haynes Informational [Page 7]
+
+RFC 7204 ReqLabeledNFS April 2014
+
+
+ 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 received 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 when any other state of the
+ objects is required to be flushed back.
+
+ The implication here is that if the client holds a delegation on an
+ object, then it enforces policy to 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 those
+ changes based on the policies of the server.
+
+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 originated
+ locally.
+
+ As 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 made
+ based upon the current client security label accessing the object,
+ rather than the security label that opened it, if different.
+
+ 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 upon 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 upon the clearances of
+ the subjects.
+
+
+
+
+
+
+
+
+Haynes Informational [Page 8]
+
+RFC 7204 ReqLabeledNFS April 2014
+
+
+3.7. Upgrading Existing Server
+
+ Note that under the MAC model, all objects MUST have labels.
+ Therefore, if an existing server is upgraded to include Labeled NFS
+ support, then it is 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 arise from the level of MAC functionality in the clients
+ and servers. The clients can be non-MAC-Functional and
+ MAC-Functional. The servers can be non-MAC-Functional, MAC-Aware,
+ and 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
+
+ The server and the client have mutually recognized MAC functionality
+ enabled, and full Labeled NFS functionality is extended over the
+ network between both client and server.
+
+ An example of an operation in Full Mode is as follows. On the
+ initial lookup, the client requests access to an object on the
+ server. It sends its process security context over to the server.
+ The server checks all relevant policies to determine if that process
+ context from that client is allowed to access the resource. Once
+ this has succeeded, the object, with its associated security
+ information, is released to the client. Once the client receives the
+ object, it determines if its policies allow the process running on
+ the client access to the object.
+
+
+
+
+
+
+
+Haynes Informational [Page 9]
+
+RFC 7204 ReqLabeledNFS April 2014
+
+
+ On subsequent operations where the client already has a handle for
+ the file, the order of enforcement is reversed. Since the client
+ already has the security context, it may make an access decision
+ against its policy first. This enables the client to avoid sending
+ requests to the server that it knows will fail, regardless of the
+ server's policy. If the client passes its policy checks, then it
+ sends the request to the server, where the client's process context
+ is used to determine if the server will release that resource to the
+ client. If both checks pass, the client is given the resource and
+ everything succeeds.
+
+ In the event that the client does not 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
+
+ The server is MAC-Aware, and the clients are MAC-Functional. The
+ server can store and transmit labels. It cannot enforce labels. 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. Indeed, it may service several different security
+ models at the same time. A client MUST process foreign labels as
+ discussed in Section 3.3. As with the Guest Mode, this mode's level
+ of trust can be degraded if non-MAC-Functional clients have access to
+ the server.
+
+4.3. Guest Mode
+
+ Only one of the server or client is MAC-Functional enabled.
+
+ In the case of the server only being MAC-Functional, the server
+ enforces its policy and may selectively provide standard NFS services
+ to clients 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.
+
+ In the case of the client only being MAC-Functional, the client MUST
+ operate as a standard NFSv4.2 (see [NFSv4_2]) client and SHOULD
+ selectively provide processes access to servers based upon the
+ security attributes of the local process, and network attributes of
+ the server, according to policy. The client may also override
+ default labeling of the remote file system based upon these security
+ attributes or other labeling methods such as mount point labeling.
+
+
+
+
+Haynes Informational [Page 10]
+
+RFC 7204 ReqLabeledNFS April 2014
+
+
+ In other words, the 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 in order to preserve its MAC guarantees.
+
+5. Use Cases
+
+ MAC labeling is meant to allow NFSv4.2 to be deployed in site-
+ configurable security schemes. The LFS and opaque data scheme allows
+ for flexibility to meet these different implementations. In this
+ section, we provide some examples of how NFSv4.2 could be deployed to
+ meet existing needs. This is not an exhaustive listing.
+
+5.1. Full MAC Labeling Support for Remotely Mounted File Systems
+
+ In this case, we assume a local networked environment where the
+ servers and clients are under common administrative control. All
+ systems in this network have the same MAC implementation and
+ semantically identical MAC security labels for objects (i.e., labels
+ mean the same thing on different systems, even if the policies on
+ each system may differ to some extent). Clients will be able to
+ apply fine-grained MAC policy to objects accessed via NFS mounts and
+ thus improve the overall consistency of MAC policy application within
+ this environment.
+
+ An example of this case would be where user home directories are
+ remotely mounted, and fine-grained MAC policy is implemented to
+ protect, for example, 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 will allow the MAC policy to
+ be implemented and provide the desired protection.
+
+5.2. MAC Labeling of Virtual Machine Images Stored on the Network
+
+ Virtualization is now a commonly implemented feature of modern
+ operating systems, and there is a need to ensure that MAC security
+ policy is able to protect virtualized resources. A common
+ implementation scheme involves storing virtualized guest file systems
+ on a networked server; these file systems are then mounted remotely
+ by guests upon instantiation. In this case, there is a need to
+ ensure that the local guest kernel is able to access fine-grained MAC
+ labels on the remotely mounted file system so that its MAC security
+ policy can be applied.
+
+
+
+
+
+
+
+
+Haynes Informational [Page 11]
+
+RFC 7204 ReqLabeledNFS April 2014
+
+
+5.3. Simple Security Label Storage
+
+ 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 that use such labels. The Labeled
+ NFS 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.
+
+5.4. Diskless Linux
+
+ A number of popular operating system distributions depend on a
+ Mandatory Access Control (MAC) model to implement a kernel-enforced
+ security policy. Typically, such models assign particular roles to
+ individual processes, which limit or permit performing certain
+ operations on a set of files, directories, sockets, or other objects.
+ While the enforcing of the policy is typically a matter for the
+ diskless NFS client itself, the file system objects in such models
+ will typically carry MAC labels that are used to define policy on
+ access. These policies may, for instance, describe privilege
+ transitions that cannot be replicated using standard NFS ACL-based
+ models.
+
+ For instance, on a SYSV-compatible system (see [SYSV]), if the 'init'
+ process spawns a process that attempts 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 this role transition, the process may find
+ itself having insufficient privileges to perform its primary job of
+ configuring network interfaces.
+
+ In setups of this type, a lot of the policy targets (such as sockets
+ or privileged system calls) are entirely local to the client. The
+ use of RPCSEC_GSSv3 ([RPC_SEC]) for enforcing compliance at the
+ server level is therefore of limited value. The ability to
+ permanently label files and have those labels read back by the client
+ is, however, crucial to the ability to enforce that policy.
+
+
+
+
+
+
+
+
+
+Haynes Informational [Page 12]
+
+RFC 7204 ReqLabeledNFS April 2014
+
+
+5.5. Multi-Level Security
+
+ In an MLS system, objects are generally assigned a sensitivity level
+ and a set of compartments. The sensitivity levels within the system
+ are given an order ranging from lowest to highest classification
+ level. Read access to an object is allowed when the sensitivity
+ level of the subject "dominates" the object it wants to access. This
+ means that the sensitivity level of the subject is higher than that
+ of the object it wishes to access and that its set of compartments is
+ a superset of the compartments on the object.
+
+ The rest of this section will just use sensitivity levels. In
+ general, the example is a client that wishes to list the contents of
+ a directory. The system defines the sensitivity levels as
+ Unclassified (U), Secret (S), and Top Secret (TS). The directory to
+ be searched is labeled Top Secret, which means access to read the
+ directory will only be granted if the subject making the request is
+ also labeled Top Secret.
+
+5.5.1. Full Mode - MAC-Functional Client and Server
+
+ In the first part of this example, a process on the client is running
+ at the Secret level. The process issues a readdir() system call,
+ which enters the kernel. Before translating the readdir() system
+ call into a request to the NFSv4.2 server, the host operating system
+ will consult the MAC module to see if the operation is allowed.
+ Since the process is operating at Secret and the directory to be
+ accessed is labeled Top Secret, the MAC module will deny the request
+ and an error code is returned to user space.
+
+ Consider a second case where instead of running at Secret the process
+ is running at Top Secret. In this case, the sensitivity of the
+ process is equal to or greater than that of the directory, so the MAC
+ module will allow the request. Now the readdir() is translated into
+ the necessary NFSv4.2 call to the server. For the remote procedure
+ call (RPC) request, the client is using the proper credential to
+ assert to the server that the process is running at Top Secret.
+
+ When the server receives 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
+ this is allowed by the policy, then the server will return the
+ appropriate information back to the client.
+
+
+
+
+
+
+
+Haynes Informational [Page 13]
+
+RFC 7204 ReqLabeledNFS April 2014
+
+
+ In this example, the policy on both the client and server is the
+ same. In the event that they were running different policies, a
+ translation of the labels might be needed. In this 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 is not 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.
+ The actions of the client will depend on whether it is configured to
+ treat the MAC-Aware server in the same manner as the non-MAC-Aware
+ one. That is, does it utilize 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 and 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 wishes 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 wishes 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 process label instead of Secret, the client would issue
+ NFSv4.2 operations to access the directory on the server.
+
+
+
+
+
+
+
+
+
+Haynes Informational [Page 14]
+
+RFC 7204 ReqLabeledNFS April 2014
+
+
+5.5.3. MAC-Functional Server
+
+ With a MAC-Functional server and a client that is not, 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 that the server is using the same criteria used 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 with 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.
+
+
+
+
+
+
+
+
+Haynes Informational [Page 15]
+
+RFC 7204 ReqLabeledNFS April 2014
+
+
+6.3. MAC-Functional Client Configuration
+
+ We defined a MAC model as an access control decision made on a system
+ in which normal users do not have the ability to override policies
+ (see Section 1). If the process labels are created solely on the
+ client, then if a malicious user has sufficient access on that
+ client, the Labeled NFS model is compromised. Note that this is no
+ different from:
+
+ o current implementations in which the server uses policies to
+ effectively determine the object label for requests from the
+ client, or
+
+ o local decisions made on the client by the MAC security system.
+
+ Either the server must explicitly trust the client (as in [SENFSv3])
+ or the MAC model should enforce that users cannot override policies,
+ perhaps via an externally managed source.
+
+ Once the labels leave the client, they can be protected by the
+ transport mechanism as described in Section 3.2.
+
+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>.
+
+
+
+
+
+Haynes Informational [Page 16]
+
+RFC 7204 ReqLabeledNFS April 2014
+
+
+ [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haynes Informational [Page 17]
+
+RFC 7204 ReqLabeledNFS April 2014
+
+
+Appendix A. Acknowledgments
+
+ David Quigley was the early energy in motivating the entire Labeled
+ NFS effort.
+
+ James Morris, Jarrett Lu, and Stephen Smalley all were key
+ contributors to both early versions of this document and to many
+ 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.
+
+ Both Nico Williams and Bryce Nordgren challenged assumptions during
+ the review processes.
+
+Author's Address
+
+ Thomas Haynes
+ NetApp
+ 495 East Java Dr.
+ Sunnyvale, CA 94089
+ USA
+
+ Phone: +1 408 215 1519
+ EMail: tdh@excfb.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haynes Informational [Page 18]
+