draft-ietf-nfsv4-labreqs-00.txt   draft-ietf-nfsv4-labreqs-01.txt 
NFSv4 T. Haynes, Ed. NFSv4 T. Haynes, Ed.
Internet-Draft NetApp Internet-Draft NetApp
Intended status: Standards Track March 29, 2012 Intended status: Standards Track May 02, 2012
Expires: September 30, 2012 Expires: November 3, 2012
Requirements for Labeled NFS Requirements for Labeled NFS
draft-ietf-nfsv4-labreqs-00.txt draft-ietf-nfsv4-labreqs-01.txt
Abstract Abstract
This Internet-Draft outlines high-level requirements for the This Internet-Draft outlines high-level requirements for the
integration of flexible Mandatory Access Control (MAC) functionality integration of flexible Mandatory Access Control (MAC) functionality
into NFSv4.2. It describes the level of protections that should be into NFSv4.2. It describes the level of protections that should be
provided over protocol components and the basic structure of the provided over protocol components and the basic structure of the
proposed system. It also gives a brief explanation of what kinds of proposed system. It also gives a brief explanation of what kinds of
protections MAC systems offer. protections MAC systems offer.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 September 30, 2012. This Internet-Draft will expire on November 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 3, line 13 skipping to change at page 3, line 13
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Portability & Interoperability . . . . . . . . . . . . . . 5 3.1. Portability & Interoperability . . . . . . . . . . . . . . 5
3.2. Performance & Scalability . . . . . . . . . . . . . . . . 6 3.2. Performance & Scalability . . . . . . . . . . . . . . . . 6
3.3. Security Services . . . . . . . . . . . . . . . . . . . . 6 3.3. Security Services . . . . . . . . . . . . . . . . . . . . 6
3.4. Label Encoding, Label Format Specifiers, and Labeling 3.4. Label Encoding, Label Format Specifiers, and Label
Authorities . . . . . . . . . . . . . . . . . . . . . . . 6 Checking Authorities . . . . . . . . . . . . . . . . . . . 7
3.5. Modes of Operation . . . . . . . . . . . . . . . . . . . . 8 3.5. Modes of Operation . . . . . . . . . . . . . . . . . . . . 8
3.5.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 8 3.5.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 8
3.5.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . . 8 3.5.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . . 8
3.6. Labeling . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.6. Labeling . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.6.1. Client Labeling . . . . . . . . . . . . . . . . . . . 9 3.6.1. Client Labeling . . . . . . . . . . . . . . . . . . . 9
3.6.2. Server Labeling . . . . . . . . . . . . . . . . . . . 9 3.6.2. Server Labeling . . . . . . . . . . . . . . . . . . . 9
3.7. Policy Enforcement . . . . . . . . . . . . . . . . . . . . 10 3.7. Policy Enforcement . . . . . . . . . . . . . . . . . . . . 10
3.7.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 10 3.7.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 10
3.7.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . . 11 3.7.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . . 11
3.8. Namespace Access . . . . . . . . . . . . . . . . . . . . . 11 3.8. Namespace Access . . . . . . . . . . . . . . . . . . . . . 11
skipping to change at page 3, line 36 skipping to change at page 3, line 36
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Full MAC labeling support for remotely mounted 4.1. Full MAC labeling support for remotely mounted
filesystems . . . . . . . . . . . . . . . . . . . . . . . 11 filesystems . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. MAC labeling of virtual machine images stored on the 4.2. MAC labeling of virtual machine images stored on the
network . . . . . . . . . . . . . . . . . . . . . . . . . 12 network . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. International Traffic in Arms Regulations (ITAR) . . . . . 12 4.3. International Traffic in Arms Regulations (ITAR) . . . . . 12
4.4. Legal Hold/eDiscovery . . . . . . . . . . . . . . . . . . 12 4.4. Legal Hold/eDiscovery . . . . . . . . . . . . . . . . . . 12
4.5. Simple security label storage . . . . . . . . . . . . . . 13 4.5. Simple security label storage . . . . . . . . . . . . . . 13
4.6. Diskless Linux . . . . . . . . . . . . . . . . . . . . . . 13 4.6. Diskless Linux . . . . . . . . . . . . . . . . . . . . . . 13
4.7. Multi-Level Security . . . . . . . . . . . . . . . . . . . 14 4.7. Multi-Level Security . . . . . . . . . . . . . . . . . . . 14
4.7.1. Full Mode - MAC functional Client and Server . . . . . 14 4.7.1. Full Mode - MAC-functional Client and Server . . . . . 14
4.7.2. MAC functional Client . . . . . . . . . . . . . . . . 15 4.7.2. MAC-Functional Client . . . . . . . . . . . . . . . . 15
4.7.3. MAC functional Server . . . . . . . . . . . . . . . . 15 4.7.3. MAC-Functional Server . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 5.1. Guest Modes . . . . . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2. MAC-Functional Client Configuration . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7.2. Informative References . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . . 17
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 17 7.2. Informative References . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction 1. Introduction
Mandatory Access Control (MAC) systems have been mainstreamed in Mandatory Access Control (MAC) systems have been mainstreamed in
modern operating systems such as Linux (R), FreeBSD (R), Solaris modern operating systems such as Linux (R), FreeBSD (R), and Solaris
(TM), and Windows Vista (R). MAC systems bind security attributes to (TM). MAC systems bind security attributes to subjects (processes)
subjects (processes) and objects within a system. These attributes and objects within a system. These attributes are used with other
are used with other information in the system to make access control 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 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
skipping to change at page 4, line 39 skipping to change at page 4, line 38
People desire to use NFSv4 with these systems. A mechanism is People desire to use NFSv4 with these systems. A mechanism is
required to provide security attribute information to NFSv4 clients required to provide security attribute information to NFSv4 clients
and servers. This mechanism has the following requirements: and servers. This mechanism has the following requirements:
(1) Clients must be able to convey to the server the security (1) Clients must be able to convey to the server the security
attribute of the subject making the access request. The server attribute of the subject making the access request. The server
may provide a mechanism to enforce MAC policy based on the may provide a mechanism to enforce MAC policy based on the
requesting subject's security attribute. requesting subject's security attribute.
(2) Server must be able to store and retrieve the security attribute (2) Servers must be able to store and retrieve the security
of exported files as requested by the client. attribute of exported files as requested by the client.
(3) Server 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.
2. Definitions 2. Definitions
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. These specifiers exist in a semantic meaning of its components. These specifiers exist in a
registry associated with documents describing the format and registry associated with documents describing the format and
semantics of the label. semantics of the label.
Label Format Registry: is the IANA registry containing all Label Format Registry: is the IANA registry (see [2]) containing all
registered LFS along with references to the documents that registered LFS along with references to the documents that
describe the syntactic format and semantics of the security label. describe the syntactic format and semantics of the security label.
Policy Identifier (PI): is an optional part of the definition of a Policy Identifier (PI): is an optional part of the definition of a
Label Format Specifier which allows for clients and server to Label Format Specifier which allows for clients and server to
identify specific security policies. identify specific security policies.
Object: is a passive resource within the system that we wish to be Object: is a passive resource within the system that we wish to be
protected. Objects can be entities such as files, directories, protected. 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.
Subject: A subject is an active entity usually a process which is Subject: is an active entity, usually a process, which is requesting
requesting access to an object. access to an object.
MAC-Aware: is a server which can transmit and store object labels.
MAC-Functional: is a client or server which is LNFS enabled. Such a
system can interpret labels and apply policies based on the
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 [8]. and a category set [5].
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 [9] and NSA's experimental NFSv3 enhancements [10]. as DTOS [6] and NSA's experimental NFSv3 enhancements [7].
3.1. Portability & Interoperability 3.1. Portability & Interoperability
LNFS must be designed with portability in mind, to facilitate LNFS must be designed with portability in mind, to facilitate
implementations on any operating system that supports mandatory implementations on any operating system that supports mandatory
access controls. access controls.
LNFS must be designed and developed to facilitate interoperability LNFS must be designed and developed to facilitate interoperability
between different LNFS implementations. between different LNFS implementations.
LNFS modifications to standard NFSv4.2 implementations must not LNFS modifications to standard NFSv4.2 [3] implementations must not
adversely impact any existing interoperability of those adversely impact any existing interoperability of those
implementations. implementations.
3.2. Performance & Scalability 3.2. Performance & Scalability
Security mechanisms often impact on system performance. LNFS should Security mechanisms often impact on system performance. LNFS should
be designed and implemented in a way which avoids significant be designed and implemented in a way which avoids significant
performance impact where possible. performance impact where possible.
As NFSv4.2 is designed for large-scale distributed networking, LNFS As NFSv4.2 is designed for large-scale distributed networking, LNFS
should also be capable of scaling in a similar manner to underlying should also be capable of scaling in a similar manner to underlying
implementations where possible. implementations where possible.
LNFS should be respond in a robust manner to system and network LNFS should respond in a robust manner to system and network outages
outages associated with typical enterprise and Internet environments. associated with typical enterprise and Internet environments. At the
At the very least, LNFS should always operate in a fail-safe manner, very least, LNFS should always operate in a fail-safe manner, so that
so that service disruptions do not cause or facilitate security service disruptions do not cause or facilitate security
vulnerabilities. vulnerabilities.
3.3. Security Services 3.3. Security Services
LNFS should ensure that the following security services are provided LNFS should ensure that the following security services are provided
for all NFSv4.2 messaging. These services may be provided by lower for all NFSv4.2 messaging. These services may be provided by lower
layers even if NFS has to be aware of and leverage them: layers even if NFS has to be aware of and leverage them:
o Authentication o Authentication
skipping to change at page 6, line 49 skipping to change at page 7, line 5
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.
LNFS should support authentication on a context granularity so that LNFS should support authentication on a context granularity so that
different contexts running on a client can use different different contexts running on a client can use different
cryptographic keys and facilities. cryptographic keys and facilities.
3.4. Label Encoding, Label Format Specifiers, and Labeling Authorities 3.4. Label Encoding, Label Format Specifiers, and Label Checking
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
should consist of an opaque component bound with a Label Format should consist of an opaque component bound with a Label Format
Specifier (LFS). The opaque component consists of the label which Specifier (LFS). The LFS component provides a mechanism for
will be interpreted by the MAC model on the other end while the LFS identifying the structure and semantics of the opaque component.
provides a mechanism for identifying the structure and semantics of Meanwhile, the opaque component is the security label which will be
the label's components. interpreted by the MAC models.
MAC models base access decisions on security attributes bound to MAC models base access decisions on security attributes bound to
subjects and objects. With a given MAC model, all systems have subjects and objects. With a given MAC model, all systems have
semantically coherent labeling - a security label must always mean semantically coherent labeling - a security label must always mean
exactly the same thing on every system. While this may not be exactly the same thing on every system. While this may not be
necessary for simple MAC models it is recommended that most label necessary for simple MAC models it is recommended that most label
formats assigned an LFS incorporate this concept into their label formats assigned an LFS incorporate this concept into their label
format. format.
LNFS must provide a means for servers and clients to identify their LNFS must provide a means for servers and clients to identify their
skipping to change at page 7, line 31 skipping to change at page 7, line 37
and security label interpretation. and security label interpretation.
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 labels. Multiple concurrent agreements may be translate each others labels. Multiple concurrent agreements may be
current between a server and a client. 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 of a system changes, it should renegotiate agreements to If the LFS supported on a system changes, it should renegotiate
reflect these changes. 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 which 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.
skipping to change at page 8, line 12 skipping to change at page 8, line 14
generalized global schemes. Future extensibility should also be generalized global schemes. Future extensibility should also be
taken into consideration. taken into consideration.
3.5. Modes of Operation 3.5. Modes of Operation
LNFS must cater for two potentially concurrent operating modes, LNFS must cater for two potentially concurrent operating modes,
depending on the state of MAC functionality: depending on the state of MAC functionality:
3.5.1. Full Mode 3.5.1. Full Mode
Both the server and the client have MAC functionality enabled, and The server and the client have mutually recognized MAC functionality
full LNFS functionality is extended over the network between both enabled, and full LNFS functionality is extended over the network
client and server. 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 local policies to determine if that The server checks all relevant policies to determine if that process
process context from that client is allowed to access the resource. context from that client is allowed to access the resource. Once
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 local policy allows the process running object it determines if its policies allow the process running on the
on the client access to the object. 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 local policy first. This enables the client to avoid against its policy first. This enables the client to avoid sending
sending requests to the server that it knows will fail regardless of requests to the server that it knows will fail regardless of the
the server's policy. If the client passes the local policy check server's policy. If the client passes its policy checks then it
then it sends the request to the server where the client's process sends the request to the server where the client's process context is
context is used to determine if the server will release that resource used to determine if the server will release that resource to the
to the client. If both checks pass, the client is given the resource client. If both checks pass, the client is given the resource and
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.
3.5.2. Guest Mode 3.5.2. Guest Mode
Only one of the server or client has MAC functionality enabled. Only one of the server or client is MAC-Functional enabled.
In the case of the server only having MAC functionality enabled, the In the case of the server only being MAC-Functional, the server
server locally enforces its policy, and may selectively provide locally enforces its policy, and may selectively provide standard NFS
standard NFS services to clients based on their authentication services to clients based on their authentication credentials and/or
credentials and/or associated network attributes (e.g. IP address, associated network attributes (e.g., IP address, network interface)
network interface) according to security policy. The level of trust according to security policy. The level of trust and access extended
and access extended to a client in this mode is configuration- to a client in this mode is configuration-specific.
specific.
In the case of the client only having MAC functionality enabled, the In the case of the client only being MAC-Functional, the client must
client must operate as a standard NFSv4.2 client, and should operate as a standard NFSv4.2 client, and should selectively provide
selectively provide processes access to servers based upon the processes access to servers based upon the security attributes of the
security attributes of the local process, and network attributes of local process, and network attributes of the server, according to
the server, according to policy. The client may also override policy. The client may also override default labeling of the remote
default labeling of the remote file system based upon these security file system based upon these security attributes, or other labeling
attributes, or other labeling methods such as mount point labeling. methods such as mount point labeling.
In other words, Guest Mode is standard NFSv4.2 over the wire, with In other words, Guest Mode is standard NFSv4.2 over the wire, with
the MAC-aware system mapping the MAC-unaware system's processes or the MAC-Functional system mapping the non-MAC-Functional system's
objects to security labels based on other characteristics in order to processes or objects to security labels based on other
preserve its local MAC guarantees. characteristics in order to preserve its MAC guarantees.
3.6. Labeling 3.6. 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.6.1. Client Labeling 3.6.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 local policy. Once that is done it label for the object based on its policy. Once that is done it will
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.6.2. Server Labeling 3.6.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.
skipping to change at page 10, line 17 skipping to change at page 10, line 18
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 should not change
the semantic meaning of the label. the semantic meaning of the label.
3.7. Policy Enforcement 3.7. Policy Enforcement
3.7.1. Full Mode 3.7.1. Full Mode
The server must enforce its local security policy over all exported The server must enforce its security policy over all exported
objects, for operations which originate both locally and remotely. objects, for operations which originate both locally and 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,
skipping to change at page 11, line 7 skipping to change at page 11, line 7
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.
3.7.2. Guest Mode 3.7.2. Guest Mode
If the server is MAC aware and the client is not, the server must not If the server is MAC-Functional and the client is not, the server
accept security labels provided by the client, and only enforce its must not accept security labels provided by the client, and only
local policy to exported objects. In the event that the client is enforce its policy to exported objects. In the event that the client
MAC aware while the server is not then the client may deny access or is MAC-Functional while the server is not then the client may deny
fall back on other methods for providing security labeling. access or fall back on other methods for providing security labeling.
3.8. Namespace Access 3.8. 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.
This is a common requirement of MLS-enabled systems, which often need This is a common requirement of MLS-enabled systems, which often need
to present selective views of namespaces based upon the clearances of to present selective views of namespaces based upon the clearances of
the subjects. the subjects.
3.9. Upgrading Existing Server 3.9. Upgrading Existing Server
Note that under the MAC model, all objects must have labels. Note that under the MAC model, all objects must have labels.
Therefore, if an existing server is upgraded to include LNFS support, Therefore, if an existing server is upgraded to include LNFS support,
then it is the responsibility of the security system to define the then it is the responsibility of the security system to define the
behavior for existing objects. For example, if the security system behavior for existing objects. For example, if the security system
is LFS 0, which means the server just stores and returns labels, then is that the server just stores and returns labels, then existing
existing files should return labels which are set to an empty value. files should return labels which are set to an empty value.
4. Use Cases 4. 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.
4.1. Full MAC labeling support for remotely mounted filesystems 4.1. Full MAC labeling support for remotely mounted filesystems
skipping to change at page 12, line 9 skipping to change at page 12, line 9
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 local MAC grained MAC labeling of the user's files will allow the MAC policy to
policy to be implemented and provide the desired protection. be implemented and provide the desired protection.
4.2. MAC labeling of virtual machine images stored on the network 4.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 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.
4.3. International Traffic in Arms Regulations (ITAR) 4.3. International Traffic in Arms Regulations (ITAR)
The International Traffic in Arms Regulations (ITAR) is put forth by The International Traffic in Arms Regulations (ITAR) is put forth by
skipping to change at page 13, line 33 skipping to change at page 13, line 33
information sensitivity (e.g., to disclosure) and information information sensitivity (e.g., to disclosure) and information
criticality (e.g., to continued business operations) need to be criticality (e.g., to continued business operations) need to be
captured. captured.
4.5. Simple security label storage 4.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 LNFS
NFS protocol would be implemented here solely to enable transport of protocol would be implemented here solely to enable transport of MAC
MAC security labels across the network. It should be noted that in security labels across the network. It should be noted that in such
such an environment, overall security cannot be as strongly enforced an environment, overall security cannot be as strongly enforced as
as in case (a), and that this scheme is aimed at allowing MAC-capable when the server is also enforcing, and that this scheme is aimed at
clients to function with local MAC security policy enabled rather allowing MAC-capable clients to function with its MAC security policy
than perhaps disabling it entirely. enabled rather than perhaps disabling it entirely.
4.6. Diskless Linux 4.6. 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
skipping to change at page 14, line 16 skipping to change at page 14, line 16
For instance on a SYSV compatible system, if the 'init' process For instance on a SYSV compatible system, if the 'init' process
spawns a process that attempts to start the 'NetworkManager' 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 for enforcing compliance at the server level is use of RPCSEC_GSSv3 ([4]) for enforcing compliance at the server
therefore of limited value. The ability to permanently label files level is therefore of limited value. The ability to permanently
and have those labels read back by the client is, however, crucial to label files and have those labels read back by the client is,
the ability to enforce that policy. however, crucial to the ability to enforce that policy.
4.7. Multi-Level Security 4.7. 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.
4.7.1. Full Mode - MAC functional Client and Server 4.7.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 which at the Secret level. The process issues a readdir() system call
enters the kernel. Before translating the readdir system call into a which enters the kernel. Before translating the readdir() system
request to the NFSv4.2 server the host operating system will consult call into a request to the NFSv4.2 server the host operating system
the MAC module to see if the operation is allowed. Since the process will consult the MAC module to see if the operation is allowed.
is operating at Secret and the directory to be accessed is labeled Since the process is operating at Secret and the directory to be
Top Secret the MAC module will deny the request and an error code is accessed is labeled Top Secret the MAC module will deny the request
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 RPC request the
client is using the proper credential to assert to the server that client is using the proper credential to assert to the server that
the process is running at Top Secret. 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 if a Top Secret process is
allowed to read the contents of the Top Secret directory. Since this allowed to read the contents of the Top Secret directory. Since this
is allowed by the policy then the server will return the appropriate is allowed by the policy then the server will return the appropriate
information back to the client. information back to the client.
skipping to change at page 15, line 29 skipping to change at page 15, line 29
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).
4.7.2. MAC functional Client 4.7.2. MAC-Functional Client
With a client that is MAC functional and a server which is not, this In these scenarios, the server is either non-MAC-Aware or MAC-Aware.
example is identical to the first part of the previous example. A The actions of the client will depend whether it is configured to
process on the client labeled Secret wishes to access a Top Secret treat the MAC-Aware server in the same manner as the non-MAC-Aware
directory. As in the previous example, this is denied since Secret one. I.e., does it utilize the approach presented in Section 3.5.2
does not dominate Top Secret. If the process were operating at Top or does it allow the MAC-Aware server to return labels?
Secret it would pass the local access control check and the NFSv4.2
operation would proceed as in a normal NFSv4.2 environment.
4.7.3. MAC functional Server With a client that is MAC-Functional and using the example in the
previous section, the result should be the same. The one difference
is that all decisions are made on the client.
With a MAC functional server and a client which is not, the client 4.7.2.1. MAC-Aware Server
A process on the client labeled Secret wishes to access a directory
labeled Top Secret on the server. This is denied since Secret does
not dominate Top Secret. Note that there will be NFSv4.2 operations
issued that return an object label for the client to process.
Note that in this scenario, all of the clients must be MAC-
Functional. A single client which does not do its access control
checks would violate the model.
4.7.2.2. Non-MAC-Aware Server
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
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
Top Secret process label, the client would issue NFSv4.2 operations
to access the directory on the server.
4.7.3. MAC-Functional Server
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.
5. Security Considerations 5. Security Considerations
5.1. 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.
5.2. MAC-Functional Client Configuration
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
Section 1). If the process labels are created solely on the client,
then if a malicious user has sufficient access on that client, the
LNFS model is compromised. Note that this is no different from:
o current implementations in which the server uses policies to
effectively determine the object label for requests from the
client, or
o local decisions made on the client by the MAC security system.
The server must either explicitly trust the client (as in [7]) or the
MAC model should enforce that users cannot override policies, perhaps
via a externally managed source.
Once the labels leave the client, they can be protected by the
transport mechanism as described in Section 3.3.
6. IANA Considerations 6. IANA Considerations
It is requested that IANA creates a registry of Label Formats to It is requested that IANA creates a registry of Label Formats to
describe the syntactic format and semantics of the security label. describe the syntactic format and semantics of the security label
(see [2]).
7. References 7. References
7.1. Normative References 7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997. Levels", March 1997.
[2] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997.
[3] Haynes, T. and N. Williams, "Remote Procedure Call (RPC)
Security Version 3", draft-williams-rpcsecgssv3 (work in
progress), 2011.
[4] Quigley, D. and J. Lu, "Registry Specification for MAC Security
Label Formats", draft-quigley-label-format-registry (work in
progress), 2011.
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [2] Quigley, D. and J. Lu, "Registry Specification for MAC Security
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Label Formats", draft-quigley-label-format-registry (work in
progress), 2011.
[6] Eisler, M., "XDR: External Data Representation Standard", [3] Haynes, T., "NFS Version 4 Minor Version 2",
RFC 4506, May 2006. draft-ietf-nfsv4-minorversion2-08 (Work In Progress),
March 2011.
[7] Shepler, S., Eisler, M., and D. Noveck, "Network File System [4] Haynes, T. and N. Williams, "Remote Procedure Call (RPC)
(NFS) Version 4 Minor Version 1 Protocol", RFC 5661, Security Version 3", draft-williams-rpcsecgssv3 (work in
January 2010. progress), 2011.
7.2. Informative References 7.2. Informative References
[8] "Section 46.6. Multi-Level Security (MLS) of Deployment Guide: [5] "Section 46.6. Multi-Level Security (MLS) of Deployment Guide:
Deployment, configuration and administration of Red Hat Deployment, configuration and administration of Red Hat
Enterprise Linux 5, Edition 6", 2011. Enterprise Linux 5, Edition 6", 2011.
[9] Smalley, S., "The Distributed Trusted Operating System (DTOS) [6] Smalley, S., "The Distributed Trusted Operating System (DTOS)
Home Page", Home Page",
<http://www.cs.utah.edu/flux/fluke/html/dtos/HTML/dtos.html>. <http://www.cs.utah.edu/flux/fluke/html/dtos/HTML/dtos.html>.
[10] Carter, J., "Implementing SELinux Support for NFS", [7] Carter, J., "Implementing SELinux Support for NFS",
<http://www.nsa.gov/selinux/papers/nfsv3-abs.cfm>. <http://www.nsa.gov/research/_files/selinux/papers/nfsv3.pdf>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
David Quigley was the early energy in motivating the entire LNFS David Quigley was the early energy in motivating the entire LNFS
effort. effort.
James Morris, Jarrett Lu, and Stephen Smalley all were key James Morris, Jarrett Lu, and Stephen Smalley all were key
contributers 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 the use cases for ITAR and Legal Hold/
eDiscovery. eDiscovery.
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
the review processes.
Appendix B. RFC Editor Notes Appendix B. RFC Editor Notes
[RFC Editor: please remove this section prior to publishing this [RFC Editor: please remove this section prior to publishing this
document as an RFC] document as an RFC]
[RFC Editor: prior to publishing this document as an RFC, please [RFC Editor: prior to publishing this document as an RFC, please
replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the
RFC number of this document] RFC number of this document]
Author's Address Author's Address
 End of changes. 53 change blocks. 
147 lines changed or deleted 194 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/