draft-ietf-nfsv4-labreqs-05.txt   rfc7204.txt 
NFSv4 T. Haynes Internet Engineering Task Force (IETF) T. Haynes
Internet-Draft NetApp Request for Comments: 7204 NetApp
Intended status: Informational December 02, 2013 Category: Informational April 2014
Expires: June 05, 2014 ISSN: 2070-1721
Requirements for Labeled NFS Requirements for Labeled NFS
draft-ietf-nfsv4-labreqs-05.txt
Abstract Abstract
This memo outlines high-level requirements for the integration of This memo outlines high-level requirements for the integration of
flexible Mandatory Access Control (MAC) functionality into the flexible Mandatory Access Control (MAC) functionality into the
Network File System (NFS) version 4.2 (NFSv4.2). It describes the Network File System (NFS) version 4.2 (NFSv4.2). It describes the
level of protections that should be provided over protocol components level of protections that should be provided over protocol components
and the basic structure of the proposed system. The intent here is and the basic structure of the proposed system. The intent here is
not to present the protocol changes, but to describe the environment not to present the protocol changes but to describe the environment
in which they reside. in which they reside.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." 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.
This Internet-Draft will expire on June 05, 2014. 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 Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definitions .....................................................3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language ......................................4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements ....................................................4
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. General ....................................................4
3.2. Security Services . . . . . . . . . . . . . . . . . . . . 5 3.2. Security Services ..........................................5
3.3. Label Encoding, Label Format Specifiers, and Label 3.3. Label Encoding, Label Format Specifiers, and Label
Checking Authorities . . . . . . . . . . . . . . . . . . 5 Checking Authorities .......................................5
3.4. Labeling . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Labeling ...................................................6
3.4.1. Client Labeling . . . . . . . . . . . . . . . . . . . 6 3.4.1. Client Labeling .....................................6
3.4.2. Server Labeling . . . . . . . . . . . . . . . . . . . 7 3.4.2. Server Labeling .....................................7
3.5. Policy Enforcement . . . . . . . . . . . . . . . . . . . 7 3.5. Policy Enforcement .........................................7
3.5.1. Client Enforcement . . . . . . . . . . . . . . . . . 7 3.5.1. Client Enforcement ..................................7
3.5.2. Server Enforcement . . . . . . . . . . . . . . . . . 8 3.5.2. Server Enforcement ..................................8
3.6. Namespace Access . . . . . . . . . . . . . . . . . . . . 8 3.6. Namespace Access ...........................................8
3.7. Upgrading Existing Server . . . . . . . . . . . . . . . . 8 3.7. Upgrading Existing Server ..................................9
4. Modes of Operation . . . . . . . . . . . . . . . . . . . . . 9 4. Modes of Operation ..............................................9
4.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Full Mode ..................................................9
4.2. Limited Server Mode . . . . . . . . . . . . . . . . . . . 10 4.2. Limited Server Mode .......................................10
4.3. Guest Mode . . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Guest Mode ................................................10
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Use Cases ......................................................11
5.1. Full MAC labeling support for remotely mounted 5.1. Full MAC Labeling Support for Remotely Mounted
filesystems . . . . . . . . . . . . . . . . . . . . . . . 11 File Systems ..............................................11
5.2. MAC labeling of virtual machine images stored on the 5.2. MAC Labeling of Virtual Machine Images Stored on
network . . . . . . . . . . . . . . . . . . . . . . . . . 11 the Network ...............................................11
5.3. Simple security label storage . . . . . . . . . . . . . . 11 5.3. Simple Security Label Storage .............................12
5.4. Diskless Linux . . . . . . . . . . . . . . . . . . . . . 12 5.4. Diskless Linux ............................................12
5.5. Multi-Level Security . . . . . . . . . . . . . . . . . . 12 5.5. Multi-Level Security ......................................13
5.5.1. Full Mode - MAC-functional Client and Server . . . . 13 5.5.1. Full Mode - MAC-Functional Client and Server .......13
5.5.2. MAC-Functional Client . . . . . . . . . . . . . . . . 14 5.5.2. MAC-Functional Client ..............................14
5.5.3. MAC-Functional Server . . . . . . . . . . . . . . . . 14 5.5.3. MAC-Functional Server ..............................15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. Security Considerations ........................................15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6.1. Trust Needed for a Community ..............................15
7.1. Trust Needed for a Community . . . . . . . . . . . . . . 15 6.2. Guest Mode ................................................15
7.2. Guest Modes . . . . . . . . . . . . . . . . . . . . . . . 15 6.3. MAC-Functional Client Configuration .......................16
7.3. MAC-Functional Client Configuration . . . . . . . . . . . 15 7. References .....................................................16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Normative References ......................................16
8.1. Normative References . . . . . . . . . . . . . . . . . . 16 7.2. Informative References ....................................16
8.2. Informative References . . . . . . . . . . . . . . . . . 16 Appendix A. Acknowledgments .......................................18
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 17
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
Mandatory Access Control (MAC) ([RFC4949]) systems have been Mandatory Access Control (MAC) systems (as defined in [RFC4949]) have
mainstreamed in modern operating systems such as Linux, FreeBSD, and been mainstreamed in modern operating systems such as Linux, FreeBSD,
Solaris. MAC systems bind security attributes to subjects and Solaris. MAC systems bind security attributes to subjects
(processes) and objects within a system. These attributes are used (processes) and objects within a system. These attributes are used
with other information in the system to make access control with other information in the system to make access control
decisions. decisions.
Access control models such as Unix permissions or Access Control Access control models such as Unix permissions or Access Control
Lists are commonly referred to as Discretionary Access Control (DAC) Lists (ACLs) are commonly referred to as Discretionary Access Control
models. These systems base their access decisions on user identity (DAC) models. These systems base their access decisions on user
and resource ownership. In contrast MAC models base their access identity and resource ownership. In contrast, MAC models base their
control decisions on the label on the subject (usually a process) and access control decisions on the label on the subject (usually a
the object it wishes to access. These labels may contain user process) and the object it wishes to access. These labels may
identity information but usually contain additional information. In contain user identity information but usually contain additional
DAC systems users are free to specify the access rules for resources information. In DAC systems, users are free to specify the access
that they own. MAC models base their security decisions on a system rules for resources that they own. MAC models base their security
wide policy established by an administrator or organization which the decisions on a system-wide policy established by an administrator or
users do not have the ability to override. DAC systems offers some organization that the users do not have the ability to override. DAC
protection against unauthorized users running malicious software. systems offer some protection against unauthorized users running
However, even an authorized user can execute malicious or flawed malicious software. However, even an authorized user can execute
software with those programs running with the full permissions of the malicious or flawed software with those programs running with the
user executing it. Inversely MAC models can confine malicious or full permissions of the user executing it. Inversely, MAC models can
flawed software and usually act at a finer granularity than their DAC confine malicious or flawed software and usually act at a finer
counterparts. granularity than their DAC counterparts.
Besides describing the requirements, this document records the Besides describing the requirements, this document records the
functional requirements for the client imposed by the pre-existing functional requirements for the client imposed by the preexisting
security models on the client. This document may help those outside security models on the client. This document may help those outside
the NFS community understand those issues. the NFS community understand those issues.
2. Definitions 2. Definitions
Foreign Label: is when a MAC implementation encounters a label in a Foreign Label: a label in a format other than the format that a MAC
format other than it uses for encoding. implementation uses for encoding.
Label Format Specifier (LFS): is an identifier used by the client to Label Format Specifier (LFS): an identifier used by the client to
establish the syntactic format of the security label and the establish the syntactic format of the security label and the
semantic meaning of its components. semantic meaning of its components.
Label Format Registry: is the IANA registry (see [lfsreg]) MAC-Aware: a server that can transmit and store object labels.
containing all registered LFS along with references to the
documents that describe the syntactic format and semantics of the
security label.
MAC-Aware: is a server which can transmit and store object labels.
MAC-Functional: is a client or server which is Labeled NFS enabled. MAC-Functional: a client or server that is Labeled NFS enabled.
Such a system can interpret labels and apply policies based on the Such a system can interpret labels and apply policies based on the
security system. security system.
Multi-Level Security (MLS): is a traditional model where objects are Multi-Level Security (MLS): a traditional model where objects are
given a sensitivity level (Unclassified, Secret, Top Secret, etc) given a sensitivity level (Unclassified, Secret, Top Secret, etc.)
and a category set [RH_MLS]. and a category set [RH_MLS].
Object: is a passive resource within the system that we wish to be Object: a passive resource within the system that we wish to
protected. Objects can be entities such as files, directories, protect. Objects can be entities such as files, directories,
pipes, sockets, and many other system resources relevant to the pipes, sockets, and many other system resources relevant to the
protection of the system state. protection of the system state.
Policy Identifier (PI): is an optional part of the definition of a Policy Identifier (PI): an optional part of the definition of a
Label Format Specifier which allows for clients and server to Label Format Specifier. The PI allows clients and servers to
identify specific security policies. identify specific security policies.
Subject: is an active entity, usually a process, which is requesting Subject: an active entity, usually a process, that is requesting
access to an object. access to an object.
2.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Requirements 3. Requirements
The following initial requirements have been gathered from users, The following initial requirements have been gathered from users and
developers, and from previous development efforts in this area such developers, and from previous development efforts in this area such
as DTOS [DTOS] and NSA's experimental NFSv3 enhancements [SENFSV3]. as the Distributed Trusted Operating System [DTOS] and the NSA's
experimental NFSv3 enhancements [SENFSv3].
3.1. General 3.1. General
A mechanism is required to provide security attribute information to A mechanism is required to provide security attribute information to
NFSv4 clients and servers. This mechanism has the following NFSv4 clients and servers. This mechanism has the following
requirements: requirements:
(1) Clients MUST be able to convey to the server the client's (1) Clients MUST be able to convey to the server the client's
priveleges, i.e., the subject, for making the access request. The privileges, i.e., the subject, for making the access request.
server may provide a mechanism to enforce MAC policy based on the The server may provide a mechanism to enforce MAC policy based
requesting client's priveleges. on the requesting client's privileges.
(2) Servers MUST be able to store and retrieve the security (2) Servers MUST be able to store and retrieve the security
attribute of exported files as requested by the client. attribute of exported files as requested by the client.
(3) Servers MUST provide a mechanism for notifying clients of (3) Servers MUST provide a mechanism for notifying clients of
attribute changes of files on the server. attribute changes of files on the server.
(4) Clients and Servers MUST be able to negotiate Label Formats and (4) Clients and Servers MUST be able to negotiate Label Formats and
provide a mechanism to translate between them as needed. provide a mechanism to translate between them as needed.
3.2. Security Services 3.2. Security Services
Labeled NFS or the underlying system on which the Labeled NFS Labeled NFS or the underlying system on which the Labeled NFS
operates MUST provide the following security services for all NFSv4.2 operates MUST provide the following security services for all NFSv4.2
messaging messaging:
o Authentication o Authentication
o Integrity o Integrity
o Privacy o Privacy
Mechanisms and algorithms used in the provision of security services Mechanisms and algorithms used in the provision of security services
MUST be configurable, so that appropriate levels of protection may be MUST be configurable so that appropriate levels of protection may be
flexibly specified per mandatory security policy. flexibly specified per mandatory security policy.
Strong mutual authentication is required between the server and the Strong mutual authentication is required between the server and the
client for Full Mode operation Section 4.1. client for Full Mode operation (Section 4.1).
MAC security labels and any related security state MUST always be MAC security labels and any related security state MUST always be
protected by these security services when transferred over the protected by these security services when transferred over the
network; as MUST the binding of labels and state to associated network, as MUST the binding of labels and state to associated
objects and subjects. objects and subjects.
Labeled NFS SHOULD support authentication on a context granularity so Labeled NFS SHOULD support authentication on a context granularity so
that different contexts running on a client can use different that different contexts running on a client can use different
cryptographic keys and facilities. cryptographic keys and facilities.
3.3. Label Encoding, Label Format Specifiers, and Label Checking 3.3. Label Encoding, Label Format Specifiers, and Label Checking
Authorities Authorities
Encoding of MAC labels and attributes passed over the network MUST be Encoding of MAC labels and attributes passed over the network MUST be
specified in a complete and unambiguous manner while maintaining the specified in a complete and unambiguous manner while maintaining the
flexibility of MAC implementations. To accomplish this the labels flexibility of MAC implementations. To accomplish this, the labels
MUST consist of a format-specific component bound with a Label Format MUST consist of a format-specific component bound with a Label Format
Specifier (LFS). The LFS component provides a mechanism for Specifier (LFS). The LFS component provides a mechanism for
identifying the structure and semantics of the opaque component. identifying the structure and semantics of the opaque component.
Meanwhile, the opaque component is the security label which will be Meanwhile, the opaque component is the security label that will be
interpreted by the MAC models. interpreted by the MAC models.
MAC models base access decisions on security attributes priveleges MAC models base access decisions on security attribute privileges
bound to subjects and objects, respectively. With a given MAC model, bound to subjects and objects, respectively. With a given MAC model,
all systems have semantically coherent labeling - a security label all systems have semantically coherent labeling -- a security label
MUST always mean exactly the same thing on every system. While this MUST always mean exactly the same thing on every system. While this
may not be necessary for simple MAC models it is recommended that may not be necessary for simple MAC models, it is recommended that
most label formats assigned an LFS incorporate semantically coherent most Label Formats assigned an LFS incorporate semantically coherent
labeling into their label format. labeling into their Label Format.
Labeled NFS SHOULD define an initial negotiation scheme with the Labeled NFS SHOULD define an initial negotiation scheme with the
primary aims of simplicity and completeness. This is to facilitate primary aims of simplicity and completeness. This is to facilitate
practical deployment of systems without being weighed down by complex practical deployment of systems without being weighed down by complex
and over-generalized global schemes. Future extensibility SHOULD and overgeneralized global schemes. Future extensibility SHOULD also
also be taken into consideration. be taken into consideration.
Labeled NFS MUST provide a means for servers and clients to identify Labeled NFS MUST provide a means for servers and clients to identify
their LFS for the purposes of authorization, security service their LFSs for the purposes of authorization, security service
selection, and security label interpretation. selection, and security label interpretation.
Labeled NFS MUST provide a means for servers and clients to identify Labeled NFS MUST provide a means for servers and clients to identify
their mode of operation (see Section 4). their mode of operation (see Section 4).
A negotiation scheme SHOULD be provided, allowing systems from A negotiation scheme SHOULD be provided, allowing systems from
different label formats to agree on how they will interpret or different Label Formats to agree on how they will interpret or
translate each others foreign labels. Multiple concurrent agreements translate each other's foreign labels. Multiple concurrent
may be current between a server and a client. agreements may be current between a server and a client.
All security labels and related security state transferred across the All security labels and related security state transferred across the
network MUST be tagged with a valid LFS. network MUST be tagged with a valid LFS.
If the LFS supported on a system changes, the system SHOULD If the LFS supported on a system changes, the system SHOULD
renegotiate agreements to reflect these changes. renegotiate agreements to reflect these changes.
If a system receives any security label or security state tagged with 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 an LFS it does not recognize or cannot interpret, it MUST reject that
label or state. label or state.
NFSv4.2 includes features which may cause a client to cross an LFS 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 boundary when accessing what appears to be a single file system. If
LFS negotiation is supported by the client and the server, the server LFS negotiation is supported by the client and the server, the server
SHOULD negotiate a new, concurrent agreement with the client, acting SHOULD negotiate a new, concurrent agreement with the client, acting
on behalf of the externally located source of the files. on behalf of the externally located source of the files.
3.4. Labeling 3.4. Labeling
Implementations MUST validate security labels supplied over the Implementations MUST validate security labels supplied over the
network to ensure that they are within a set of labels permitted from 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 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. permit a different set of labels to be accepted from each peer.
3.4.1. Client Labeling 3.4.1. Client Labeling
At the client, labeling semantics for NFS mounted file systems MUST At the client, labeling semantics for NFS mounted file systems MUST
remain consistent with those for locally mounted file systems. In remain consistent with those for locally mounted file systems. In
particular, user-level labeling operations local to the client MUST particular, user-level labeling operations local to the client MUST
be enacted locally via existing APIs, to ensure compatibility and be enacted locally via existing APIs, to ensure compatibility and
consistency for applications and libraries. consistency for applications and libraries.
Note that this does not imply any specific mechanism for conveying Note that this does not imply any specific mechanism for conveying
labels over the network. labels over the network.
When an object is newly created by the client, it will calculate the 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 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 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. 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 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 to the object before the object becomes visible to the rest of the
system. This ensures that any access control or further labeling system. This ensures that any access control or further labeling
decisions are correct for the object. decisions are correct for the object.
3.4.2. Server Labeling 3.4.2. Server Labeling
The server MUST provide the capability for clients to retrieve The server MUST provide the capability for clients to retrieve
security labels on all exported file system objects where possible. security labels on all exported file system objects where possible.
This includes cases where only in-core and/or read-only security This includes cases where only in-core and/or read-only security
labels are available at the server for any of its exported file labels are available at the server for any of its exported file
systems. systems.
The server MUST honor the ability for a client to specify the label 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 of an object on creation. If the server is MAC enabled, it may
to reject the label specified by the client due to restrictions in choose to reject the label specified by the client, due to
the server policy. The server SHOULD NOT attempt to find a suitable restrictions in the server policy. The server SHOULD NOT attempt to
label for an object in event of different labeling rules on its end. find a suitable label for an object in the event of different
The server is allowed to translate the label but MUST NOT change the labeling rules on its end. The server is allowed to translate the
semantic meaning of the label. label but MUST NOT change the semantic meaning of the label.
3.5. Policy Enforcement 3.5. Policy Enforcement
The MAC-Functional client determines if a process request is sent to The MAC-Functional client determines if a process request is sent to
the remote server. Upon a successful response from the server, it the remote server. Upon a successful response from the server, it
must use its own policies on the object's security labels to must use its own policies on the object's security labels to
determine if the process can be given access. The client SHOULD NOT determine if the process can be given access. The client SHOULD NOT
need to be cognizant if the server is either a Limited Server or need to be cognizant of whether the server is a Limited Server or is
fully MAC-Functional. fully MAC-Functional.
3.5.1. Client Enforcement 3.5.1. Client Enforcement
The client MUST apply its own policy to remotely located objects, The client MUST apply its own policy to remotely located objects,
using security labels for the objects obtained from the server. It using security labels for the objects obtained from the server. It
MUST be possible to configure the maximum length of time a client may MUST be possible to configure the maximum length of time a client may
cache state regarding remote labels before re-validating that state cache state regarding remote labels before revalidating that state
with the server. with the server.
If the server's policy changes, the client MUST flush all object 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 back to the server. The server MUST ensure that any flushed
state received is consistent with current policy before committing it state received is consistent with current policy before committing it
to stable storage. to stable storage.
Any local security state associated with cached or delegated objects Any local security state associated with cached or delegated objects
MUST also be flushed back to the server when any other state of the MUST also be flushed back to the server when any other state of the
objects is required to be flushed back. objects is required to be flushed back.
The implication here is that if the client holds a delegation on an 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 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 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 to the server, it SHOULD be prepared for the server to reject those
changes based on the policies of the server. changes based on the policies of the server.
3.5.2. Server Enforcement 3.5.2. Server Enforcement
A MAC-Functional server MUST enforce its security policy over all A MAC-Functional server MUST enforce its security policy over all
exported objects, for operations which originate both locally and exported objects, for operations that originate both locally and
remotely. remotely.
Requests from authenticated clients MUST be processed using security Requests from authenticated clients MUST be processed using security
labels and credentials supplied by the client as if they originated labels and credentials supplied by the client as if they originated
locally. locally.
As with labeling, the system MUST also take into account any other As with labeling, the system MUST also take into account any other
volatile client security state, such as a change in process security volatile client security state, such as a change in process security
context via dynamic transition. Access decisions SHOULD also be made context via dynamic transition. Access decisions SHOULD also be made
based upon the current client security label accessing the object, based upon the current client security label accessing the object,
rather than the security label which opened it, if different. rather than the security label that opened it, if different.
The server SHOULD recall delegation of an object if the object's The server SHOULD recall delegation of an object if the object's
security label changes. security label changes.
3.6. Namespace Access 3.6. Namespace Access
The server SHOULD provide a means to authorize selective access to The server SHOULD provide a means to authorize selective access to
the exported file system namespace based upon client credentials and the exported file system namespace based upon client credentials and
according to security policy. according to security policy.
skipping to change at page 9, line 13 skipping to change at page 9, line 18
Therefore, if an existing server is upgraded to include Labeled NFS Therefore, if an existing server is upgraded to include Labeled NFS
support, then it is the responsibility of the security system to support, then it is the responsibility of the security system to
define the behavior for existing objects. define the behavior for existing objects.
4. Modes of Operation 4. Modes of Operation
In a Labeled NFS client and server interaction, we can describe three In a Labeled NFS client and server interaction, we can describe three
modes of operation: modes of operation:
1. Full 1. Full
2. Limited Server 2. Limited Server
3. Guest 3. Guest
These modes arise from the level of MAC functionality in the clients These modes arise from the level of MAC functionality in the clients
and servers. The clients can be non-MAC-Functional and MAC- and servers. The clients can be non-MAC-Functional and
Functional. The servers can be non-MAC-Functional, MAC-Aware, and MAC-Functional. The servers can be non-MAC-Functional, MAC-Aware,
MAC-Functional. and MAC-Functional.
A MAC-Functional client MUST be able to determine the level of MAC A MAC-Functional client MUST be able to determine the level of MAC
functionality in the server. Likewise, a MAC-Functional server MUST functionality in the server. Likewise, a MAC-Functional server MUST
be able to determine whether or not a client is MAC-Functional. As 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 discussed in Section 3.3, the protocol MUST provide for the client
and server to make those determinations. and server to make those determinations.
4.1. Full Mode 4.1. Full Mode
The server and the client have mutually recognized MAC functionality The server and the client have mutually recognized MAC functionality
enabled, and full Labeled NFS functionality is extended over the enabled, and full Labeled NFS functionality is extended over the
network between both client and server. network between both client and server.
An example of an operation in full mode is as follows. On the An example of an operation in Full Mode is as follows. On the
initial lookup, the client requests access to an object on the initial lookup, the client requests access to an object on the
server. It sends its process security context over to the server. server. It sends its process security context over to the server.
The server checks all relevant policies to determine if that process The server checks all relevant policies to determine if that process
context from that client is allowed to access the resource. Once context from that client is allowed to access the resource. Once
this has succeeded the object with its associated security this has succeeded, the object, with its associated security
information is released to the client. Once the client receives the information, is released to the client. Once the client receives the
object it determines if its policies allow the process running on the object, it determines if its policies allow the process running on
client access to the object. the client access to the object.
On subsequent operations where the client already has a handle for On subsequent operations where the client already has a handle for
the file, the order of enforcement is reversed. Since the client the file, the order of enforcement is reversed. Since the client
already has the security context it may make an access decision already has the security context, it may make an access decision
against its policy first. This enables the client to avoid sending against its policy first. This enables the client to avoid sending
requests to the server that it knows will fail regardless of the requests to the server that it knows will fail, regardless of the
server's policy. If the client passes its policy checks then it 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 sends the request to the server, where the client's process context
used to determine if the server will release that resource to the 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 client. If both checks pass, the client is given the resource and
everything succeeds. everything succeeds.
In the event that the client does not trust the server, it may opt to 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 use an alternate labeling mechanism, regardless of the server's
ability to return security information. ability to return security information.
4.2. Limited Server Mode 4.2. Limited Server Mode
The server is MAC-Aware and the clients are MAC-Functional. The The server is MAC-Aware, and the clients are MAC-Functional. The
server can store and transmit labels. It cannot enforce labels. The server can store and transmit labels. It cannot enforce labels. The
server MUST inform clients when an object label changes for a file server MUST inform clients when an object label changes for a file
the client has open. the client has open.
In this mode, the server may not be aware of the format of any its 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 object labels. Indeed, it may service several different security
models at the same time. A client MUST process foreign labels as 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 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 of trust can be degraded if non-MAC-Functional clients have access to
the server. the server.
4.3. Guest Mode 4.3. Guest Mode
Only one of the server or client is MAC-Functional enabled. Only one of the server or client is MAC-Functional enabled.
In the case of the server only being MAC-Functional, the server In the case of the server only being MAC-Functional, the server
enforces its policy, and may selectively provide standard NFS enforces its policy and may selectively provide standard NFS services
services to clients based on their authentication credentials and/or to clients based on their authentication credentials and/or
associated network attributes (e.g., IP address, network interface) associated network attributes (e.g., IP address, network interface)
according to security policy. The level of trust and access extended according to security policy. The level of trust and access extended
to a client in this mode is configuration-specific. to a client in this mode is configuration-specific.
In the case of the client only being MAC-Functional, the client MUST In the case of the client only being MAC-Functional, the client MUST
operate as a standard NFSv4.2 (see [I-D.ietf-nfsv4-minorversion2]) operate as a standard NFSv4.2 (see [NFSv4_2]) client and SHOULD
client, and SHOULD selectively provide processes access to servers selectively provide processes access to servers based upon the
based upon the security attributes of the local process, and network security attributes of the local process, and network attributes of
attributes of the server, according to policy. The client may also the server, according to policy. The client may also override
override default labeling of the remote file system based upon these default labeling of the remote file system based upon these security
security attributes, or other labeling methods such as mount point attributes or other labeling methods such as mount point labeling.
labeling.
In other words, Guest Mode is standard NFSv4.2 over the wire, with In other words, the Guest Mode is standard NFSv4.2 over the wire,
the MAC-Functional system mapping the non-MAC-Functional system's with the MAC-Functional system mapping the non-MAC-Functional
processes or objects to security labels based on other system's processes or objects to security labels based on other
characteristics in order to preserve its MAC guarantees. characteristics in order to preserve its MAC guarantees.
5. Use Cases 5. Use Cases
MAC labeling is meant to allow NFSv4.2 to be deployed in site MAC labeling is meant to allow NFSv4.2 to be deployed in site-
configurable security schemes. The LFS and opaque data scheme allows configurable security schemes. The LFS and opaque data scheme allows
for flexibility to meet these different implementations. In this for flexibility to meet these different implementations. In this
section, we provide some examples of how NFSv4.2 could be deployed to section, we provide some examples of how NFSv4.2 could be deployed to
meet existing needs. This is not an exhaustive listing. meet existing needs. This is not an exhaustive listing.
5.1. Full MAC labeling support for remotely mounted filesystems 5.1. Full MAC Labeling Support for Remotely Mounted File Systems
In this case, we assume a local networked environment where the In this case, we assume a local networked environment where the
servers and clients are under common administrative control. All servers and clients are under common administrative control. All
systems in this network have the same MAC implementation and systems in this network have the same MAC implementation and
semantically identical MAC security labels for objects (i.e. labels semantically identical MAC security labels for objects (i.e., labels
mean the same thing on different systems, even if the policies on mean the same thing on different systems, even if the policies on
each system may differ to some extent). Clients will be able to each system may differ to some extent). Clients will be able to
apply fine-grained MAC policy to objects accessed via NFS mounts, and apply fine-grained MAC policy to objects accessed via NFS mounts and
thus improve the overall consistency of MAC policy application within thus improve the overall consistency of MAC policy application within
this environment. this environment.
An example of this case would be where user home directories are An example of this case would be where user home directories are
remotely mounted, and fine-grained MAC policy is implemented to remotely mounted, and fine-grained MAC policy is implemented to
protect, for example, private user data from being read by malicious protect, for example, private user data from being read by malicious
web scripts running in the user's browser. With Labeled NFS, fine- 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 grained MAC labeling of the user's files will allow the MAC policy to
be implemented and provide the desired protection. be implemented and provide the desired protection.
5.2. MAC labeling of virtual machine images stored on the network 5.2. MAC Labeling of Virtual Machine Images Stored on the Network
Virtualization is now a commonly implemented feature of modern Virtualization is now a commonly implemented feature of modern
operating systems, and there is a need to ensure that MAC security operating systems, and there is a need to ensure that MAC security
policy is able to protect virtualized resources. A common policy is able to protect virtualized resources. A common
implementation scheme involves storing virtualized guest filesystems implementation scheme involves storing virtualized guest file systems
on a networked server, which are then mounted remotely by guests upon on a networked server; these file systems are then mounted remotely
instantiation. In this case, there is a need to ensure that the by guests upon instantiation. In this case, there is a need to
local guest kernel is able to access fine-grained MAC labels on the ensure that the local guest kernel is able to access fine-grained MAC
remotely mounted filesystem so that its MAC security policy can be labels on the remotely mounted file system so that its MAC security
applied. policy can be applied.
5.3. Simple security label storage 5.3. Simple Security Label Storage
In this case, a mixed and loosely administered network is assumed, In this case, a mixed and loosely administered network is assumed,
where nodes may be running a variety of operating systems with where nodes may be running a variety of operating systems with
different security mechanisms and security policies. It is desired different security mechanisms and security policies. It is desired
that network file servers be simply capable of storing and retrieving that network file servers be simply capable of storing and retrieving
MAC security labels for clients which use such labels. The Labeled MAC security labels for clients that use such labels. The Labeled
NFS protocol would be implemented here solely to enable transport of NFS protocol would be implemented here solely to enable transport of
MAC security labels across the network. It should be noted that in MAC security labels across the network. It should be noted that in
such an environment, overall security cannot be as strongly enforced such an environment, overall security cannot be as strongly enforced
as when the server is also enforcing, and that this scheme is aimed as when the server is also enforcing and that this scheme is aimed at
at allowing MAC-capable clients to function with its MAC security allowing MAC-capable clients to function with its MAC security policy
policy enabled rather than perhaps disabling it entirely. enabled rather than perhaps disabling it entirely.
5.4. Diskless Linux 5.4. Diskless Linux
A number of popular operating system distributions depend on a A number of popular operating system distributions depend on a
mandatory access control (MAC) model to implement a kernel-enforced Mandatory Access Control (MAC) model to implement a kernel-enforced
security policy. Typically, such models assign particular roles to security policy. Typically, such models assign particular roles to
individual processes, which limit or permit performing certain individual processes, which limit or permit performing certain
operations on a set of files, directories, sockets, or other objects. operations on a set of files, directories, sockets, or other objects.
While the enforcing of the policy is typically a matter for the While the enforcing of the policy is typically a matter for the
diskless NFS client itself, the filesystem objects in such models diskless NFS client itself, the file system objects in such models
will typically carry MAC labels that are used to define policy on will typically carry MAC labels that are used to define policy on
access. These policies may, for instance, describe privilege access. These policies may, for instance, describe privilege
transitions that cannot be replicated using standard NFS ACL based transitions that cannot be replicated using standard NFS ACL-based
models. models.
For instance on a SYSV compatible system, if the 'init' process For instance, on a SYSV-compatible system (see [SYSV]), if the 'init'
spawns a process that attempts to start the 'NetworkManager' process spawns a process that attempts to start the 'NetworkManager'
executable, there may be a policy that sets up a role transition if executable, there may be a policy that sets up a role transition if
the 'init' process and 'NetworkManager' file labels match a the 'init' process and 'NetworkManager' file labels match a
particular rule. Without this role transition, the process may find particular rule. Without this role transition, the process may find
itself having insufficient privileges to perform its primary job of itself having insufficient privileges to perform its primary job of
configuring network interfaces. configuring network interfaces.
In setups of this type, a lot of the policy targets (such as sockets 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 or privileged system calls) are entirely local to the client. The
use of RPCSEC_GSSv3 ([rpcsecgssv3]) for enforcing compliance at the use of RPCSEC_GSSv3 ([RPC_SEC]) for enforcing compliance at the
server level is therefore of limited value. The ability to server level is therefore of limited value. The ability to
permanently label files and have those labels read back by the client permanently label files and have those labels read back by the client
is, however, crucial to the ability to enforce that policy. is, however, crucial to the ability to enforce that policy.
5.5. Multi-Level Security 5.5. Multi-Level Security
In a MLS system objects are generally assigned a sensitivity level
In an MLS system, objects are generally assigned a sensitivity level
and a set of compartments. The sensitivity levels within the system and a set of compartments. The sensitivity levels within the system
are given an order ranging from lowest to highest classification are given an order ranging from lowest to highest classification
level. Read access to an object is allowed when the sensitivity level. Read access to an object is allowed when the sensitivity
level of the subject "dominates" the object it wants to access. This level of the subject "dominates" the object it wants to access. This
means that the sensitivity level of the subject is higher than that 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 of the object it wishes to access and that its set of compartments is
a super-set of the compartments on the object. a superset of the compartments on the object.
The rest of the section will just use sensitivity levels. In general The rest of this section will just use sensitivity levels. In
the example is a client that wishes to list the contents of a general, the example is a client that wishes to list the contents of
directory. The system defines the sensitivity levels as Unclassified a directory. The system defines the sensitivity levels as
(U), Secret (S), and Top Secret (TS). The directory to be searched Unclassified (U), Secret (S), and Top Secret (TS). The directory to
is labeled Top Secret which means access to read the directory will be searched is labeled Top Secret, which means access to read the
only be granted if the subject making the request is also labeled Top directory will only be granted if the subject making the request is
Secret. also labeled Top Secret.
5.5.1. Full Mode - MAC-functional Client and Server 5.5.1. Full Mode - MAC-Functional Client and Server
In the first part of this example a process on the client is running 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 at the Secret level. The process issues a readdir() system call,
which enters the kernel. Before translating the readdir() system which enters the kernel. Before translating the readdir() system
call into a request to the NFSv4.2 server the host operating 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. will consult the MAC module to see if the operation is allowed.
Since the process is operating at Secret and the directory to be Since the process is operating at Secret and the directory to be
accessed is labeled Top Secret the MAC module will deny the request accessed is labeled Top Secret, the MAC module will deny the request
and an error code is returned to user space. and an error code is returned to user space.
Consider a second case where instead of running at Secret the process Consider a second case where instead of running at Secret the process
is running at Top Secret. In this case the sensitivity of the 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 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 module will allow the request. Now the readdir() is translated into
the necessary NFSv4.2 call to the server. For the RPC request the the necessary NFSv4.2 call to the server. For the remote procedure
client is using the proper credential to assert to the server that call (RPC) request, the client is using the proper credential to
the process is running at Top Secret. assert to the server that the process is running at Top Secret.
When the server receives the request it extracts the security label When the server receives the request, it extracts the security label
from the RPC session and retrieves the label on the directory. The from the RPC session and retrieves the label on the directory. The
server then checks with its MAC module if a Top Secret process is server then checks with its MAC module to see if a Top Secret process
allowed to read the contents of the Top Secret directory. Since this is allowed to read the contents of the Top Secret directory. Since
is allowed by the policy then the server will return the appropriate this is allowed by the policy, then the server will return the
information back to the client. appropriate information back to the client.
In this example the policy on the client and server were both the In this example, the policy on both the client and server is the
same. In the event that they were running different policies a same. In the event that they were running different policies, a
translation of the labels might be needed. In this case it could be 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. possible for a check to pass on the client and fail on the server.
The server may consider additional information when making its policy The server may consider additional information when making its policy
decisions. For example the server could determine that a certain decisions. For example, the server could determine that a certain
subnet is only cleared for data up to Secret classification. If that subnet is only cleared for data up to Secret classification. If that
constraint was in place for the example above the client would still constraint was in place for the example above, the client would still
succeed, but the server would fail since the client is asserting a 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). label that it is not able to use (Top Secret on a Secret network).
5.5.2. MAC-Functional Client 5.5.2. MAC-Functional Client
In these scenarios, the server is either non-MAC-Aware or MAC-Aware. In these scenarios, the server is either non-MAC-Aware or MAC-Aware.
The actions of the client will depend whether it is configured to 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 treat the MAC-Aware server in the same manner as the non-MAC-Aware
one. I.e., does it utilize the approach presented in Section 4.3 or one. That is, does it utilize the approach presented in Section 4.3,
does it allow the MAC-Aware server to return labels? or does it allow the MAC-Aware server to return labels?
With a client that is MAC-Functional and using the example in the With a client that is MAC-Functional and using the example in the
previous section, the result should be the same. The one difference previous section, the result should be the same. The one difference
is that all decisions are made on the client. is that all decisions are made on the client.
5.5.2.1. MAC-Aware Server 5.5.2.1. MAC-Aware Server
A process on the client labeled Secret wishes to access a directory A process on the client labeled Secret wishes to access a directory
labeled Top Secret on the server. This is denied since Secret does labeled Top Secret on the server. This is denied, since Secret does
not dominate Top Secret. Note that there will be NFSv4.2 operations not dominate Top Secret. Note that there will be NFSv4.2 operations
issued that return an object label for the client to process. issued that return an object label for the client to process.
Note that in this scenario, all of the clients must be MAC- Note that in this scenario, all of the clients must be
Functional. A single client which does not do its access control MAC-Functional. A single client that does not do its access control
checks would violate the model. checks would violate the model.
5.5.2.2. Non-MAC-Aware Server 5.5.2.2. Non-MAC-Aware Server
A process on the client labeled Secret wishes to access a directory A process on the client labeled Secret wishes to access a directory
which the client's policies label as Top Secret on the server. This 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 is denied, since Secret does not dominate Top Secret. Note that
will not be NFSv4.2 operations issued. If the process had instead a there will not be NFSv4.2 operations issued. If the process had a
Top Secret process label, the client would issue NFSv4.2 operations Top Secret process label instead of Secret, the client would issue
to access the directory on the server. NFSv4.2 operations to access the directory on the server.
5.5.3. MAC-Functional Server 5.5.3. MAC-Functional Server
With a MAC-Functional server and a client which is not, the client 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 behaves as if it were in a normal NFSv4.2 environment. Since the
process on the client does not provide a security attribute the process on the client does not provide a security attribute, the
server must define a mechanism for labeling all requests from a server must define a mechanism for labeling all requests from a
client. Assume that the server is using the same criteria used in client. Assume that the server is using the same criteria used in
the first example. The server sees the request as coming from a the first example. The server sees the request as coming from a
subnet that is a Secret network. The server determines that all subnet that is a Secret network. The server determines that all
clients on that subnet will have their requests labeled with Secret. clients on that subnet will have their requests labeled with Secret.
Since the directory on the server is labeled Top Secret and 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 does not dominate Top Secret, the server would fail the request with
NFS4ERR_ACCESS. NFS4ERR_ACCESS.
6. IANA Considerations 6. Security Considerations
This document has no actions for IANA.
7. Security Considerations
7.1. Trust Needed for a Community 6.1. Trust Needed for a Community
Labeled NFS is a transport mechanism for labels, a storage Labeled NFS is a transport mechanism for labels, a storage
requirement for labels, and a definition of how to interpret labels. requirement for labels, and a definition of how to interpret labels.
It defines the responsibilities of the client and the server in the It defines the responsibilities of the client and the server in the
various permutations of being MAC-Functional. It does not however various permutations of being MAC-Functional. It does not, however,
dictate in any manner whether assumptions can be made about other dictate in any manner whether assumptions can be made about other
entities in the relationship. For example, it does not define entities in the relationship. For example, it does not define
whether a MAC-Functional client can demand that a MAC-Aware server whether a MAC-Functional client can demand that a MAC-Aware server
only accept requests from other MAC-Functional clients. That is a only accept requests from other MAC-Functional clients. That is a
policy based in a MAC model and this document does not impose policy based on a MAC model, and this document does not impose
policies on systems. policies on systems.
As the requirement is a policy, it can be met with the use of a MAC As the requirement is a policy, it can be met with the use of a MAC
model. Let L be a LFS which implements the Limited Server mode, 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 i.e., a MAC-Aware server connected to MAC-Functional clients. Then
new LFS L' can be created which has the additional policy that the a new LFS, L', can be created that has the additional policy that
MAC-Aware server MUST NOT accept any requests from a non-MAC- the MAC-Aware server MUST NOT accept any requests from a
Functional client. non-MAC-Functional client.
7.2. Guest Modes 6.2. Guest Mode
When either the client or server is operating in guest mode it is When either the client or server is operating in Guest Mode, it is
important to realize that one side is not enforcing MAC protections. important to realize that one side is not enforcing MAC protections.
Alternate methods are being used to handle the lack of MAC support Alternate methods are being used to handle the lack of MAC support,
and care should be taken to identify and mitigate threats from and care should be taken to identify and mitigate threats from
possible tampering outside of these methods. possible tampering outside of these methods.
7.3. MAC-Functional Client Configuration 6.3. MAC-Functional Client Configuration
We defined a MAC model as a access control decision made on a system We defined a MAC model as an access control decision made on a system
which normal users do not have the ability to override policies (see in which normal users do not have the ability to override policies
Section 1). If the process labels are created solely on the client, (see Section 1). If the process labels are created solely on the
then if a malicious user has sufficient access on that client, the client, then if a malicious user has sufficient access on that
Labeled NFS model is compromised. Note that this is no different client, the Labeled NFS model is compromised. Note that this is no
from: different from:
o current implementations in which the server uses policies to o current implementations in which the server uses policies to
effectively determine the object label for requests from the effectively determine the object label for requests from the
client, or client, or
o local decisions made on the client by the MAC security system. o local decisions made on the client by the MAC security system.
The server must either explicitly trust the client (as in [SENFSV3]) Either the server must explicitly trust the client (as in [SENFSv3])
or the MAC model should enforce that users cannot override policies, or the MAC model should enforce that users cannot override policies,
perhaps via a externally managed source. perhaps via an externally managed source.
Once the labels leave the client, they can be protected by the Once the labels leave the client, they can be protected by the
transport mechanism as described in Section 3.2. transport mechanism as described in Section 3.2.
8. References 7. References
8.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References 7.2. Informative References
[DTOS] Smalley, S., "The Distributed Trusted Operating System [DTOS] Smalley, S., "The Distributed Trusted Operating System
(DTOS) Home Page ", December 2000, <http://www.cs.utah.edu (DTOS) Home Page", December 2000, <http://www.cs.utah.edu/
/flux/fluke/html/dtos/HTML/dtos.html>. flux/fluke/html/dtos/HTML/dtos.html>.
[I-D.ietf-nfsv4-minorversion2] [NFSv4_2] Haynes, T., "NFS Version 4 Minor Version 2", Work in
Haynes, T., "NFS Version 4 Minor Version 2", draft-ietf- Progress, February 2014.
nfsv4-minorversion2-21 (Work In Progress), November 2013.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
August 2007. 4949, August 2007.
[RH_MLS] "Section 46.6. Multi-Level Security (MLS) of Deployment [RH_MLS] "Multi-Level Security (MLS)", "Deployment, configuration
Guide: Deployment, configuration and administration of Red and administration of Red Hat Enterprise Linux 5, Edition
Hat Enterprise Linux 5, Edition 6 ", 2011. 10", Section 49.6, 2014, <http://docs.redhat.com/docs/
en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/
sec-mls-ov.html>.
[SENFSV3] Carter, J., "Implementing SELinux Support for NFS", , [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/ <http://www.nsa.gov/research/_files/selinux/papers/
nfsv3.pdf>. nfsv3.pdf>.
[lfsreg] Quigley, D. and J. Lu, "Registry Specification for MAC [SYSV] AT&T, "System V Interface Definition (SVID)", Third
Security Label Formats", draft-quigley-label-format- Edition, Addison-Wesley, Reading, MA, 1989.
registry (work in progress), 2011.
[rpcsecgssv3]
Adamson, W. and N. Williams, "Remote Procedure Call (RPC)
Security Version 3", draft-ietf-nfsv4-rpcsec-gssv3-05
(Work In Progress), October 2013.
Appendix A. Acknowledgments Appendix A. Acknowledgments
David Quigley was the early energy in motivating the entire Labeled David Quigley was the early energy in motivating the entire Labeled
NFS effort. NFS effort.
James Morris, Jarrett Lu, and Stephen Smalley all were key James Morris, Jarrett Lu, and Stephen Smalley all were key
contributors to both early versions of this document and to many contributors to both early versions of this document and to many
conference calls. conference calls.
Kathleen Moriarty provided use cases for earlier versions of the Kathleen Moriarty provided use cases for earlier versions of the
draft. document.
Dan Walsh provided use cases for Secure Virtualization, Sandboxing, Dan Walsh provided use cases for Secure Virtualization, Sandboxing,
and NFS homedir labeling to handle process separation. and NFS homedir labeling to handle process separation.
Trond Myklebust provided use cases for secure diskless NFS clients. Trond Myklebust provided use cases for secure diskless NFS clients.
Both Nico Williams and Bryce Nordgren challenged assumptions during Both Nico Williams and Bryce Nordgren challenged assumptions during
the review processes. the review processes.
Appendix B. RFC Editor Notes
[RFC Editor: please remove this section prior to publishing this
document as an RFC]
[RFC Editor: prior to publishing this document as an RFC, please
replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the
RFC number of this document]
Author's Address Author's Address
Thomas Haynes Thomas Haynes
NetApp NetApp
495 E Java Dr 495 East Java Dr.
Sunnyvale, CA 95054 Sunnyvale, CA 94089
USA USA
Phone: +1 408 419 3018 Phone: +1 408 215 1519
Email: thomas@netapp.com EMail: tdh@excfb.com
 End of changes. 125 change blocks. 
294 lines changed or deleted 273 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/