draft-ietf-nfsv4-labreqs-04.txt   draft-ietf-nfsv4-labreqs-05.txt 
NFSv4 T. Haynes NFSv4 T. Haynes
Internet-Draft NetApp Internet-Draft NetApp
Intended status: Informational August 04, 2013 Intended status: Informational December 02, 2013
Expires: February 5, 2014 Expires: June 05, 2014
Requirements for Labeled NFS Requirements for Labeled NFS
draft-ietf-nfsv4-labreqs-04.txt 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 5, 2014. This Internet-Draft will expire on June 05, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Security Services . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . 6 Checking Authorities . . . . . . . . . . . . . . . . . . 5
3.4. Labeling . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Labeling . . . . . . . . . . . . . . . . . . . . . . . . 6
3.4.1. Client Labeling . . . . . . . . . . . . . . . . . . . 7 3.4.1. Client Labeling . . . . . . . . . . . . . . . . . . . 6
3.4.2. Server Labeling . . . . . . . . . . . . . . . . . . . 8 3.4.2. Server Labeling . . . . . . . . . . . . . . . . . . . 7
3.5. Policy Enforcement . . . . . . . . . . . . . . . . . . . . 8 3.5. Policy Enforcement . . . . . . . . . . . . . . . . . . . 7
3.5.1. Client Enforcement . . . . . . . . . . . . . . . . . . 8 3.5.1. Client Enforcement . . . . . . . . . . . . . . . . . 7
3.5.2. Server Enforcement . . . . . . . . . . . . . . . . . . 9 3.5.2. Server Enforcement . . . . . . . . . . . . . . . . . 8
3.6. Namespace Access . . . . . . . . . . . . . . . . . . . . . 9 3.6. Namespace Access . . . . . . . . . . . . . . . . . . . . 8
3.7. Upgrading Existing Server . . . . . . . . . . . . . . . . 9 3.7. Upgrading Existing Server . . . . . . . . . . . . . . . . 8
4. Modes of Operation . . . . . . . . . . . . . . . . . . . . . . 10 4. Modes of Operation . . . . . . . . . . . . . . . . . . . . . 9
4.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Limited Server Mode . . . . . . . . . . . . . . . . . . . 11 4.2. Limited Server Mode . . . . . . . . . . . . . . . . . . . 10
4.3. Guest Mode . . . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . . . 12 filesystems . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. MAC labeling of virtual machine images stored on the 5.2. MAC labeling of virtual machine images stored on the
network . . . . . . . . . . . . . . . . . . . . . . . . . 12 network . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. International Traffic in Arms Regulations (ITAR) . . . . . 12 5.3. Simple security label storage . . . . . . . . . . . . . . 11
5.4. Legal Hold/eDiscovery . . . . . . . . . . . . . . . . . . 13 5.4. Diskless Linux . . . . . . . . . . . . . . . . . . . . . 12
5.5. Simple security label storage . . . . . . . . . . . . . . 13 5.5. Multi-Level Security . . . . . . . . . . . . . . . . . . 12
5.6. Diskless Linux . . . . . . . . . . . . . . . . . . . . . . 14 5.5.1. Full Mode - MAC-functional Client and Server . . . . 13
5.7. Multi-Level Security . . . . . . . . . . . . . . . . . . . 14 5.5.2. MAC-Functional Client . . . . . . . . . . . . . . . . 14
5.7.1. Full Mode - MAC-functional Client and Server . . . . . 15 5.5.3. MAC-Functional Server . . . . . . . . . . . . . . . . 14
5.7.2. MAC-Functional Client . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
5.7.3. MAC-Functional Server . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7.1. Trust Needed for a Community . . . . . . . . . . . . . . 15
6.1. Trust Needed for a Community . . . . . . . . . . . . . . . 16 7.2. Guest Modes . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Guest Modes . . . . . . . . . . . . . . . . . . . . . . . 17 7.3. MAC-Functional Client Configuration . . . . . . . . . . . 15
6.3. MAC-Functional Client Configuration . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . . 18 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 17
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 17
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
Mandatory Access Control (MAC) systems have been mainstreamed in Mandatory Access Control (MAC) ([RFC4949]) systems have been
modern operating systems such as Linux, FreeBSD, and Solaris. MAC mainstreamed in modern operating systems such as Linux, FreeBSD, and
systems bind security attributes to subjects (processes) and objects Solaris. MAC systems bind security attributes to subjects
within a system. These attributes are used with other information in (processes) and objects within a system. These attributes are used
the system to make access control decisions. with other information in the system to make access control
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 are commonly referred to as Discretionary Access Control (DAC)
models. These systems base their access decisions on user identity models. These systems base their access decisions on user identity
and resource ownership. In contrast MAC models base their access and resource ownership. In contrast MAC models base their access
control decisions on the label on the subject (usually a process) and control decisions on the label on the subject (usually a process) and
the object it wishes to access. These labels may contain user the object it wishes to access. These labels may contain user
identity information but usually contain additional information. In identity information but usually contain additional information. In
DAC systems users are free to specify the access rules for resources DAC systems users are free to specify the access rules for resources
that they own. MAC models base their security decisions on a system that they own. MAC models base their security decisions on a system
wide policy established by an administrator or organization which the wide policy established by an administrator or organization which the
users do not have the ability to override. DAC systems offer no real users do not have the ability to override. DAC systems offers some
protection against malicious or flawed software due to each program protection against unauthorized users running malicious software.
running with the full permissions of the user executing it. However, even an authorized user can execute malicious or flawed
Inversely MAC models can confine malicious or flawed software and software with those programs running with the full permissions of the
usually act at a finer granularity than their DAC counterparts. 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 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 pre-existing
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
format other than it uses for encoding.
Label Format Specifier (LFS): is an identifier used by the client to Label Format Specifier (LFS): is 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]) Label Format Registry: is the IANA registry (see [lfsreg])
containing all registered LFS along with references to the containing all registered LFS along with references to the
documents that describe the syntactic format and semantics of the documents that describe the syntactic format and semantics of the
security label. security label.
Policy Identifier (PI): is an optional part of the definition of a
Label Format Specifier which allows for clients and server to
identify specific security policies.
Object: is a passive resource within the system that we wish to be
protected. Objects can be entities such as files, directories,
pipes, sockets, and many other system resources relevant to the
protection of the system state.
Subject: is an active entity, usually a process, which is requesting
access to an object.
MAC-Aware: is a server which can transmit and store object labels. 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: is a client or server which 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): is 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
protected. 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): is an optional part of the definition of a
Label Format Specifier which allows for clients and server to
identify specific security policies.
Subject: is an active entity, usually a process, which is requesting
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,
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 DTOS [DTOS] and 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 security (1) Clients MUST be able to convey to the server the client's
attribute of the subject making the access request. The server priveleges, i.e., the subject, for making the access request. The
may provide a mechanism to enforce MAC policy based on the server may provide a mechanism to enforce MAC policy based on the
requesting subject's security attribute. requesting client's priveleges.
(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 SHOULD support that the following security services are Labeled NFS or the underlying system on which the Labeled NFS
provided for all NFSv4.2 messaging. These services may be provided operates MUST provide the following security services for all NFSv4.2
by lower layers even if NFS has to be aware of and leverage them: 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 will be required between the server and Strong mutual authentication is required between the server and the
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 SHOULD 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 SHOULD 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 an opaque 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 which will be
interpreted by the MAC models. interpreted by the MAC models.
MAC models base access decisions on security attributes bound to MAC models base access decisions on security attributes priveleges
subjects and objects. With a given MAC model, all systems have bound to subjects and objects, respectively. With a given MAC model,
semantically coherent labeling - a security label MUST always mean all systems have semantically coherent labeling - a security label
exactly the same thing on every system. While this may not be MUST always mean exactly the same thing on every system. While this
necessary for simple MAC models it is recommended that most label may not be necessary for simple MAC models it is recommended that
formats assigned an LFS incorporate this concept into their label most label formats assigned an LFS incorporate semantically coherent
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 over-generalized global schemes. Future extensibility SHOULD
also be taken into consideration. also 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 LFS for the purposes of authorization, security service
selection, and security label interpretation. selection, and security label interpretation.
skipping to change at page 8, line 33 skipping to change at page 7, line 30
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 choose
to reject the label specified by the client due to restrictions in to reject the label specified by the client due to restrictions in
the server policy. The server SHOULD NOT attempt to find a suitable the server policy. The server SHOULD NOT attempt to find a suitable
label for an object in event of different labeling rules on its end. label for an object in event of different labeling rules on its end.
The server is allowed to translate the label but SHOULD NOT change The server is allowed to translate the label but MUST NOT change the
the semantic meaning of the label. 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 if the server is either a Limited Server or
fully MAC-Functional. fully MAC-Functional.
skipping to change at page 12, line 39 skipping to change at page 11, line 49
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 filesystems
on a networked server, which are then mounted remotely by guests upon on a networked server, which are then mounted remotely by guests upon
instantiation. In this case, there is a need to ensure that the 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 local guest kernel is able to access fine-grained MAC labels on the
remotely mounted filesystem so that its MAC security policy can be remotely mounted filesystem so that its MAC security policy can be
applied. applied.
5.3. International Traffic in Arms Regulations (ITAR) 5.3. Simple security label storage
The International Traffic in Arms Regulations (ITAR) is put forth by
the United States Department of State, Directorate of Defense and
Trade Controls. ITAR places strict requirements on the export and
thus access of defense articles and defense services. Organizations
that manage projects with articles and services deemed as within the
scope of ITAR must ensure the regulations are met. The regulations
require an assurance that ITAR information is accessed on a need-to-
know basis, thus requiring strict, centrally managed access controls
on items labeled as ITAR. Additionally, organizations must be able
to prove that the controls were adequately maintained and that
foreign nationals were not permitted access to these defense articles
or service. ITAR control applicability may be dynamic; information
may become subject to ITAR after creation (e.g., when the defense
implications of technology are recognized).
5.4. Legal Hold/eDiscovery
Increased cases of legal holds on electronic sources of information
(ESI) have resulted in organizations taking a pro-active approach to
reduce the scope and thus costs associated with these activities.
ESI Data Maps are increasing in use and require support in operating
systems to strictly manage access controls in the case of a legal
hold. The sizeable quantity of information involved in a legal
discovery request may preclude making a copy of the information to a
separate system that manages the legal hold on the copies; this
results in a need to enforce the legal hold on the original
information.
Organizations are taking steps to map out the sources of information
that are most likely to be placed under a legal hold, these efforts
result in ESI Data Maps. ESI Data Maps specify the Electronic Source
of Information and the requirements for sensitivity and criticality.
In the case of a legal hold, the ESI data map and labels can be used
to ensure the legal hold is properly enforced on the predetermined
set of information. An ESI data map narrows the scope of a legal
hold to the predetermined ESI. The information must then be
protected at a level of security of which the weight and
admissibility of that evidence may be proved in a court of law.
Current systems use application level controls and do not adequately
meet the requirements. Labels may be used in advance when an ESI
data map exercise is conducted with controls being applied at the
time of a hold or labels may be applied to data sets during an
eDiscovery exercise to ensure the data protections are adequate
during the legal hold period.
Note that this use case requires multi-attribute labels, as both
information sensitivity (e.g., to disclosure) and information
criticality (e.g., to continued business operations) need to be
captured.
5.5. 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 which 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 allowing MAC-capable clients to function with its MAC security at allowing MAC-capable clients to function with its MAC security
policy enabled rather than perhaps disabling it entirely. policy enabled rather than perhaps disabling it entirely.
5.6. 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 filesystem 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
skipping to change at page 14, line 38 skipping to change at page 12, line 43
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 ([rpcsecgssv3]) 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.7. Multi-Level Security 5.5. Multi-Level Security
In a MLS system objects are generally assigned a sensitivity level In a 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 super-set of the compartments on the object.
The rest of the section will just use sensitivity levels. In general The rest of the section will just use sensitivity levels. In general
the example is a client that wishes to list the contents of a the example is a client that wishes to list the contents of a
directory. The system defines the sensitivity levels as Unclassified directory. The system defines the sensitivity levels as Unclassified
(U), Secret (S), and Top Secret (TS). The directory to be searched (U), Secret (S), and Top Secret (TS). The directory to be searched
is labeled Top Secret which means access to read the directory will 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 only be granted if the subject making the request is also labeled Top
Secret. Secret.
5.7.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.
skipping to change at page 15, line 46 skipping to change at page 14, line 10
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.7.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 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. I.e., does it utilize the approach presented in Section 4.3 or
does it allow the MAC-Aware server to return labels? 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.7.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 MAC-
Functional. A single client which does not do its access control Functional. A single client which does not do its access control
checks would violate the model. checks would violate the model.
5.7.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 which 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 there
will not be NFSv4.2 operations issued. If the process had instead a will not be NFSv4.2 operations issued. If the process had instead a
Top Secret process label, the client would issue NFSv4.2 operations Top Secret process label, the client would issue NFSv4.2 operations
to access the directory on the server. to access the directory on the server.
5.7.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 which 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. Security Considerations 6. IANA Considerations
6.1. Trust Needed for a Community This document has no actions for IANA.
7. Security Considerations
7.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 in 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 a LFS which 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 a
new LFS L' can be created which has the additional policy that the new LFS L' can be created which has the additional policy that the
MAC-Aware server MUST NOT accept any requests from a non-MAC- MAC-Aware server MUST NOT accept any requests from a non-MAC-
Functional client. Functional client.
6.2. Guest Modes 7.2. Guest Modes
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.
6.3. MAC-Functional Client Configuration 7.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 a access control decision made on a system
which normal users do not have the ability to override policies (see which normal users do not have the ability to override policies (see
Section 1). If the process labels are created solely on the client, Section 1). If the process labels are created solely on the client,
then if a malicious user has sufficient access on that client, the then if a malicious user has sufficient access on that client, the
Labeled NFS model is compromised. Note that this is no different Labeled NFS model is compromised. Note that this is no different
from: 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
skipping to change at page 17, line 49 skipping to change at page 16, line 18
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]) The server must either 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 a 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.
7. References 8. References
7.1. Normative References
8.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", March 1997.
7.2. Informative References 8.2. Informative References
[DTOS] Smalley, S., "The Distributed Trusted Operating System [DTOS] Smalley, S., "The Distributed Trusted Operating System
(DTOS) Home Page", <http://www.cs.utah.edu/flux/fluke/ (DTOS) Home Page ", December 2000, <http://www.cs.utah.edu
html/dtos/HTML/dtos.html>. /flux/fluke/html/dtos/HTML/dtos.html>.
[I-D.ietf-nfsv4-minorversion2] [I-D.ietf-nfsv4-minorversion2]
Haynes, T. and D. Noveck, "NFS Version 4 Minor Version 2", Haynes, T., "NFS Version 4 Minor Version 2", draft-ietf-
draft-ietf-nfsv4-minorversion2-19 (Work In Progress), nfsv4-minorversion2-21 (Work In Progress), November 2013.
March 2013.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2",
August 2007.
[RH_MLS] "Section 46.6. Multi-Level Security (MLS) of Deployment [RH_MLS] "Section 46.6. Multi-Level Security (MLS) of Deployment
Guide: Deployment, configuration and administration of Red Guide: Deployment, configuration and administration of Red
Hat Enterprise Linux 5, Edition 6", 2011. Hat Enterprise Linux 5, Edition 6 ", 2011.
[SENFSV3] Carter, J., "Implementing SELinux Support for NFS", <http: [SENFSV3] Carter, J., "Implementing SELinux Support for NFS", ,
//www.nsa.gov/research/_files/selinux/papers/nfsv3.pdf>. <http://www.nsa.gov/research/_files/selinux/papers/
nfsv3.pdf>.
[lfsreg] Quigley, D. and J. Lu, "Registry Specification for MAC [lfsreg] Quigley, D. and J. Lu, "Registry Specification for MAC
Security Label Formats", Security Label Formats", draft-quigley-label-format-
draft-quigley-label-format-registry (work in progress), registry (work in progress), 2011.
2011.
[rpcsecgssv3] [rpcsecgssv3]
Haynes, T. and N. Williams, "Remote Procedure Call (RPC) Adamson, W. and N. Williams, "Remote Procedure Call (RPC)
Security Version 3", draft-williams-rpcsecgssv3 (work in Security Version 3", draft-ietf-nfsv4-rpcsec-gssv3-05
progress), 2011. (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 the use cases for ITAR and Legal Hold/ Kathleen Moriarty provided use cases for earlier versions of the
eDiscovery. draft.
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 Appendix B. RFC Editor Notes
 End of changes. 46 change blocks. 
175 lines changed or deleted 136 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/