draft-ietf-nfsv4-labreqs-01.txt   draft-ietf-nfsv4-labreqs-02.txt 
NFSv4 T. Haynes, Ed. NFSv4 T. Haynes, Ed.
Internet-Draft NetApp Internet-Draft NetApp
Intended status: Standards Track May 02, 2012 Intended status: Standards Track May 11, 2012
Expires: November 3, 2012 Expires: November 12, 2012
Requirements for Labeled NFS Requirements for Labeled NFS
draft-ietf-nfsv4-labreqs-01.txt draft-ietf-nfsv4-labreqs-02.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 November 3, 2012. This Internet-Draft will expire on November 12, 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 17 skipping to change at page 3, line 17
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 Label 3.4. Label Encoding, Label Format Specifiers, and Label
Checking Authorities . . . . . . . . . . . . . . . . . . . 7 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. Limited Server Mode . . . . . . . . . . . . . . . . . 9
3.5.3. Guest Mode . . . . . . . . . . . . . . . . . . . . . . 9
3.6. Labeling . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.6. Labeling . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.6.1. Client Labeling . . . . . . . . . . . . . . . . . . . 9 3.6.1. Client Labeling . . . . . . . . . . . . . . . . . . . 10
3.6.2. Server Labeling . . . . . . . . . . . . . . . . . . . 9 3.6.2. Server Labeling . . . . . . . . . . . . . . . . . . . 10
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
3.9. Upgrading Existing Server . . . . . . . . . . . . . . . . 11 3.9. Upgrading Existing Server . . . . . . . . . . . . . . . . 12
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Full MAC labeling support for remotely mounted 4.1. Full MAC labeling support for remotely mounted
filesystems . . . . . . . . . . . . . . . . . . . . . . . 11 filesystems . . . . . . . . . . . . . . . . . . . . . . . 12
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) . . . . . 13
4.4. Legal Hold/eDiscovery . . . . . . . . . . . . . . . . . . 12 4.4. Legal Hold/eDiscovery . . . . . . . . . . . . . . . . . . 13
4.5. Simple security label storage . . . . . . . . . . . . . . 13 4.5. Simple security label storage . . . . . . . . . . . . . . 14
4.6. Diskless Linux . . . . . . . . . . . . . . . . . . . . . . 13 4.6. Diskless Linux . . . . . . . . . . . . . . . . . . . . . . 14
4.7. Multi-Level Security . . . . . . . . . . . . . . . . . . . 14 4.7. Multi-Level Security . . . . . . . . . . . . . . . . . . . 15
4.7.1. Full Mode - MAC-functional Client and Server . . . . . 14 4.7.1. Full Mode - MAC-functional Client and Server . . . . . 15
4.7.2. MAC-Functional Client . . . . . . . . . . . . . . . . 15 4.7.2. MAC-Functional Client . . . . . . . . . . . . . . . . 16
4.7.3. MAC-Functional Server . . . . . . . . . . . . . . . . 16 4.7.3. MAC-Functional Server . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5.1. Guest Modes . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Guest Modes . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. MAC-Functional Client Configuration . . . . . . . . . . . 16 5.2. MAC-Functional Client Configuration . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . . 17 7.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 18 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
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), and Solaris modern operating systems such as Linux (R), FreeBSD (R), and Solaris
(TM). MAC systems bind security attributes to subjects (processes) (TM). MAC systems bind security attributes to subjects (processes)
and objects within a system. These attributes are used with other and objects within a system. These attributes are used with other
information in the system to make access control decisions. 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
skipping to change at page 4, line 33 skipping to change at page 4, line 33
users do not have the ability to override. DAC systems offer no real users do not have the ability to override. DAC systems offer no real
protection against malicious or flawed software due to each program protection against malicious or flawed software due to each program
running with the full permissions of the user executing it. running with the full permissions of the user executing it.
Inversely MAC models can confine malicious or flawed software and Inversely MAC models can confine malicious or flawed software and
usually act at a finer granularity than their DAC counterparts. usually act at a finer granularity than their DAC counterparts.
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) 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.
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.
registry associated with documents describing the format and
semantics of the label.
Label Format Registry: is the IANA registry (see [2]) 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
skipping to change at page 5, line 44 skipping to change at page 5, line 42
and a category set [5]. 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 [6] and NSA's experimental NFSv3 enhancements [7]. 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 [3] 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 respond in a robust manner to system and network outages LNFS SHOULD respond in a robust manner to system and network outages
associated with typical enterprise and Internet environments. At the associated with typical enterprise and Internet environments. At the
very least, LNFS should always operate in a fail-safe manner, so that very least, LNFS SHOULD always operate in a fail-safe manner, 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
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 will be required between the server and
the client for Full Mode operation Section 3.5.1. the client for Full Mode operation Section 3.5.1.
MAC security labels and any related security state must always be MAC security labels and any related security state SHOULD 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 SHOULD 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 Label Checking 3.4. 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
should consist of an opaque component bound with a Label Format MUST consist of an opaque 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 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
LFS for the purposes of authorization, security service selection, LFS for the purposes of authorization, security service selection,
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 supported on a system changes, it should renegotiate If the LFS supported on a system changes, it SHOULD renegotiate
agreements to 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.
LNFS should define an initial negotiation scheme with the primary LNFS SHOULD define an initial negotiation scheme with the primary
aims of simplicity and completeness. This is to facilitate practical aims of simplicity and completeness. This is to facilitate practical
deployment of systems without being weighed down by complex and over- deployment of systems without being weighed down by complex and over-
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, In a LNFS client and server interaction, we can describe three modes
depending on the state of MAC functionality: of operation:
1. Full
2. Limited Server
3. Guest
These modes arise from the level of MAC functionality in the clients
and servers. The clients can be non-MAC-Functional and MAC-
Functional. The servers can be non-MAC-Functional, MAC-Aware, and
MAC-Functional.
A MAC-Functional client MUST be able to determine the level of MAC
functionality in the server. Likewise, a MAC-Functional server MUST
be able to determine whether or not a client is MAC-Functional.
3.5.1. Full Mode 3.5.1. Full Mode
The server and the client have mutually recognized MAC functionality The server and the client have mutually recognized MAC functionality
enabled, and full LNFS functionality is extended over the network enabled, and full LNFS functionality is extended over the network
between both 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.
skipping to change at page 8, line 43 skipping to change at page 9, line 10
server's policy. If the client passes its policy checks then it server's policy. If the client passes its policy checks then it
sends the request to the server where the client's process context is sends the request to the server where the client's process context is
used to determine if the server will release that resource to the used to determine if the server will release that resource to the
client. If both checks pass, the client is given the resource and client. If both checks pass, the client is given the resource and
everything succeeds. everything succeeds.
In the event that the client does not trust the server, it may opt to In the event that the client does not trust the server, it may opt to
use an alternate labeling mechanism regardless of the server's use an alternate labeling mechanism regardless of the server's
ability to return security information. ability to return security information.
3.5.2. Guest Mode 3.5.2. Limited Server Mode
The server is MAC-Aware and the clients are MAC-Functional. The
server can store and transmit labels. It cannot enforce labels. The
server SHOULD inform clients when an object label changes for a file
the client has open.
In this mode, the server may not be aware of the format of any its
object labels. Indeed, it may service several different security
models at the same time. A client MUST process foreign labels as
discussed in Section 3.4. As with the Guest Mode, this mode's level
of trust can be degraded if non-MAC-functional clients have access to
the server.
3.5.3. Guest Mode
Only one of the server or client is MAC-Functional enabled. Only one of the server or client is MAC-Functional enabled.
In the case of the server only being MAC-Functional, the server In the case of the server only being MAC-Functional, the server
locally enforces its policy, and may selectively provide standard NFS enforces its policy, and may selectively provide standard NFS
services to clients based on their authentication credentials and/or services to clients based on their authentication credentials and/or
associated network attributes (e.g., IP address, network interface) associated network attributes (e.g., IP address, network interface)
according to security policy. The level of trust and access extended according to security policy. The level of trust and access extended
to a client in this mode is configuration-specific. to a client in this mode is configuration-specific.
In the case of the client only being MAC-Functional, the client must In the case of the client only being MAC-Functional, the client MUST
operate as a standard NFSv4.2 client, and should selectively provide operate as a standard NFSv4.2 client, and SHOULD selectively provide
processes access to servers based upon the security attributes of the processes access to servers based upon the security attributes of the
local process, and network attributes of the server, according to local process, and network attributes of the server, according to
policy. The client may also override default labeling of the remote policy. The client may also override default labeling of the remote
file system based upon these security attributes, or other labeling file system based upon these security 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-Functional system mapping the non-MAC-Functional system's the MAC-Functional system mapping the non-MAC-Functional system's
processes or objects to security labels based on other processes or objects to security labels based on other
characteristics in order to preserve its MAC guarantees. characteristics in order to preserve its MAC guarantees.
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 policy. Once that is done it will label for the object based on its policy. Once that is done it will
send the request to the server which has the ability to deny the send the request to the server which has the ability to deny the
creation of the object with that label based on the server's policy. creation of the object with that label based on the server's policy.
In creating the file the server must ensure that the label is bound In creating the file the server MUST ensure that the label is bound
to the object before the object becomes visible to the rest of the to the object before the object becomes visible to the rest of the
system. This ensures that any access control or further labeling system. This ensures that any access control or further labeling
decisions are correct for the object. decisions are correct for the object.
3.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.
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 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 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,
rather than the security label which opened it, if different. rather than the security label which opened it, if different.
The client must apply its own policy to remotely located objects, The client MUST apply its own policy to remotely located objects,
using security labels for the objects obtained from the server. It using security labels for the objects obtained from the server. It
must be possible to configure the maximum length of time a client may MUST be possible to configure the maximum length of time a client may
cache state regarding remote labels before re-validating that state cache state regarding remote labels before re-validating that state
with the server. with the server.
The server must recall delegation of an object if the object's The server MUST recall delegation of an object if the object's
security label changes. security label changes.
A mechanism must exist to allow the client to obtain access, and A mechanism MUST exist to allow the client to obtain access, and
labeling decisions from the server for locally cached and delegated labeling decisions from the server for locally cached and delegated
objects, so that it may apply the server's policy to these objects. objects, so that it may apply the server's policy to these objects.
If the server's policy changes, the client must flush all object If the server's policy changes, the client MUST flush all object
state back to the server. The server must ensure that any flushed state back to the server. The server MUST ensure that any flushed
state received is consistent with current policy before committing it state received is consistent with current policy before committing it
to stable storage. to stable storage.
Any local security state associated with cached or delegated objects Any local security state associated with cached or delegated objects
must also be flushed back to the server when any other state of the MUST also be flushed back to the server when any other state of the
objects is required to be flushed back. objects is required to be flushed back.
3.7.2. Guest Mode 3.7.2. Guest Mode
If the server is MAC-Functional and the client is not, the server If the server is MAC-Functional and the client is not, the server
must not accept security labels provided by the client, and only MUST not accept security labels provided by the client, and only
enforce its policy to exported objects. In the event that the client enforce its policy to exported objects. In the event that the client
is MAC-Functional while the server is not then the client may deny is MAC-Functional while the server is not then the client may deny
access or 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.
is that the server just stores and returns labels, then existing
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 15, line 34 skipping to change at page 16, line 17
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
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 3.5.2 one. I.e., does it utilize the approach presented in Section 3.5.3
or does it allow the MAC-Aware server to return labels? or does it allow the MAC-Aware server to return labels?
With a client that is MAC-Functional and using the example in the With a client that is MAC-Functional and using the example in the
previous section, the result should be the same. The one difference previous section, the result should be the same. The one difference
is that all decisions are made on the client. is that all decisions are made on the client.
4.7.2.1. MAC-Aware Server 4.7.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
 End of changes. 66 change blocks. 
87 lines changed or deleted 113 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/