GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7204

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7204.txt · Last modified: 2014/04/17 22:50 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki