draft-ietf-nfsv4-labreqs-02.txt   draft-ietf-nfsv4-labreqs-03.txt 
NFSv4 T. Haynes, Ed. NFSv4 T. Haynes, Ed.
Internet-Draft NetApp Internet-Draft NetApp
Intended status: Standards Track May 11, 2012 Intended status: Standards Track May 18, 2012
Expires: November 12, 2012 Expires: November 19, 2012
Requirements for Labeled NFS Requirements for Labeled NFS
draft-ietf-nfsv4-labreqs-02.txt draft-ietf-nfsv4-labreqs-03.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 12, 2012. This Internet-Draft will expire on November 19, 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 23 skipping to change at page 3, line 23
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. Limited Server Mode . . . . . . . . . . . . . . . . . 9 3.5.2. Limited Server Mode . . . . . . . . . . . . . . . . . 9
3.5.3. Guest Mode . . . . . . . . . . . . . . . . . . . . . . 9 3.5.3. Guest Mode . . . . . . . . . . . . . . . . . . . . . . 9
3.6. Labeling . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.6. Labeling . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.6.1. Client Labeling . . . . . . . . . . . . . . . . . . . 10 3.6.1. Client Labeling . . . . . . . . . . . . . . . . . . . 10
3.6.2. Server Labeling . . . . . . . . . . . . . . . . . . . 10 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. Client Enforcement . . . . . . . . . . . . . . . . . . 11
3.7.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . . 11 3.7.2. Server Enforcement . . . . . . . . . . . . . . . . . . 11
3.8. Namespace Access . . . . . . . . . . . . . . . . . . . . . 11 3.8. Namespace Access . . . . . . . . . . . . . . . . . . . . . 11
3.9. Upgrading Existing Server . . . . . . . . . . . . . . . . 12 3.9. Upgrading Existing Server . . . . . . . . . . . . . . . . 12
4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Full MAC labeling support for remotely mounted 4.1. Full MAC labeling support for remotely mounted
filesystems . . . . . . . . . . . . . . . . . . . . . . . 12 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) . . . . . 13 4.3. International Traffic in Arms Regulations (ITAR) . . . . . 13
4.4. Legal Hold/eDiscovery . . . . . . . . . . . . . . . . . . 13 4.4. Legal Hold/eDiscovery . . . . . . . . . . . . . . . . . . 13
4.5. Simple security label storage . . . . . . . . . . . . . . 14 4.5. Simple security label storage . . . . . . . . . . . . . . 14
4.6. Diskless Linux . . . . . . . . . . . . . . . . . . . . . . 14 4.6. Diskless Linux . . . . . . . . . . . . . . . . . . . . . . 14
4.7. Multi-Level Security . . . . . . . . . . . . . . . . . . . 15 4.7. Multi-Level Security . . . . . . . . . . . . . . . . . . . 15
4.7.1. Full Mode - MAC-functional Client and Server . . . . . 15 4.7.1. Full Mode - MAC-functional Client and Server . . . . . 15
4.7.2. MAC-Functional Client . . . . . . . . . . . . . . . . 16 4.7.2. MAC-Functional Client . . . . . . . . . . . . . . . . 16
4.7.3. MAC-Functional Server . . . . . . . . . . . . . . . . 16 4.7.3. MAC-Functional Server . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5.1. Guest Modes . . . . . . . . . . . . . . . . . . . . . . . 17 5.1. Trust Needed for a Community . . . . . . . . . . . . . . . 17
5.2. MAC-Functional Client Configuration . . . . . . . . . . . 17 5.2. Guest Modes . . . . . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5.3. MAC-Functional Client Configuration . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . . 18 7.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 19
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 19 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 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.
skipping to change at page 5, line 26 skipping to change at page 5, line 26
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: is an active entity, usually a process, which is requesting Subject: is an active entity, usually a process, which is requesting
access to an object. access to an object.
MAC-Aware: is a server which can transmit and store object labels. MAC-Aware: is a server which can transmit and store object labels.
MAC-Functional: is a client or server which is LNFS enabled. Such a MAC-Functional: is a client or server which is Labeled NFS enabled.
system can interpret labels and apply policies based on the Such a system can interpret labels and apply policies based on the
security system. security system.
Multi-Level Security (MLS): is a traditional model where objects are Multi-Level Security (MLS): is a traditional model where objects are
given a sensitivity level (Unclassified, Secret, Top Secret, etc) given a sensitivity level (Unclassified, Secret, Top Secret, etc)
and a category set [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 Labeled NFS 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 Labeled NFS MUST be designed and developed to facilitate
between different LNFS implementations. interoperability between different Labeled NFS implementations.
LNFS modifications to standard NFSv4.2 [3] implementations MUST not Labeled NFS modifications to standard NFSv4.2 [3] implementations
adversely impact any existing interoperability of those MUST not 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. Labeled NFS
be designed and implemented in a way which avoids significant SHOULD 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,
SHOULD also be capable of scaling in a similar manner to underlying Labeled NFS SHOULD also be capable of scaling in a similar manner to
implementations where possible. underlying implementations where possible.
LNFS SHOULD respond in a robust manner to system and network outages Labeled NFS SHOULD respond in a robust manner to system and network
associated with typical enterprise and Internet environments. At the outages associated with typical enterprise and Internet environments.
very least, LNFS SHOULD always operate in a fail-safe manner, so that At the very least, Labeled NFS SHOULD always operate in a fail-safe
service disruptions do not cause or facilitate security manner, so that service disruptions do not cause or facilitate
vulnerabilities. security vulnerabilities.
3.3. Security Services 3.3. Security Services
LNFS SHOULD ensure that the following security services are provided Labeled NFS SHOULD ensure that the following security services are
for all NFSv4.2 messaging. These services may be provided by lower provided for all NFSv4.2 messaging. These services may be provided
layers even if NFS has to be aware of and leverage them: by lower 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 SHOULD 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 SHOULD 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 Labeled NFS SHOULD support authentication on a context granularity so
different contexts running on a client can use different that different contexts running on a client can use different
cryptographic keys and facilities. cryptographic keys and facilities.
3.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
MUST 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
skipping to change at page 7, line 25 skipping to change at page 7, line 25
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 Labeled NFS MUST provide a means for servers and clients to identify
LFS for the purposes of authorization, security service selection, their LFS for the purposes of authorization, security service
and security label interpretation. selection, 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
skipping to change at page 7, line 50 skipping to change at page 7, line 50
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 Labeled NFS SHOULD define an initial negotiation scheme with the
aims of simplicity and completeness. This is to facilitate practical primary aims of simplicity and completeness. This is to facilitate
deployment of systems without being weighed down by complex and over- practical deployment of systems without being weighed down by complex
generalized global schemes. Future extensibility SHOULD also be and over-generalized global schemes. Future extensibility SHOULD
taken into consideration. also be taken into consideration.
3.5. Modes of Operation 3.5. Modes of Operation
In a LNFS client and server interaction, we can describe three modes In a Labeled NFS client and server interaction, we can describe three
of operation: modes of operation:
1. Full 1. Full
2. Limited Server 2. Limited Server
3. Guest 3. Guest
These modes arise from the level of MAC functionality in the clients These modes arise from the level of MAC functionality in the clients
and servers. The clients can be non-MAC-Functional and MAC- and servers. The clients can be non-MAC-Functional and MAC-
Functional. The servers can be non-MAC-Functional, MAC-Aware, and Functional. The servers can be non-MAC-Functional, MAC-Aware, and
MAC-Functional. MAC-Functional.
A MAC-Functional client MUST be able to determine the level of MAC A MAC-Functional client MUST be able to determine the level of MAC
functionality in the server. Likewise, a MAC-Functional server MUST functionality in the server. Likewise, a MAC-Functional server MUST
be able to determine whether or not a client is MAC-Functional. 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 Labeled NFS functionality is extended over the
between both client and server. network between both client and server.
An example of an operation in full mode is as follows. On the An example of an operation in full mode is as follows. On the
initial lookup, the client requests access to an object on the initial lookup, the client requests access to an object on the
server. It sends its process security context over to the server. server. It sends its process security context over to the server.
The server checks all relevant policies to determine if that process The server checks all relevant policies to determine if that process
context from that client is allowed to access the resource. Once context from that client is allowed to access the resource. Once
this has succeeded the object with its associated security this has succeeded the object with its associated security
information is released to the client. Once the client receives the information is released to the client. Once the client receives the
object it determines if its policies allow the process running on the object it determines if its policies allow the process running on the
client access to the object. client access to the object.
skipping to change at page 9, line 14 skipping to change at page 9, line 14
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. Limited Server Mode 3.5.2. Limited Server Mode
The server is MAC-Aware and the clients are MAC-Functional. The The server is MAC-Aware and the clients are MAC-Functional. The
server can store and transmit labels. It cannot enforce labels. The server can store and transmit labels. It cannot enforce labels. The
server SHOULD inform clients when an object label changes for a file server MUST inform clients when an object label changes for a file
the client has open. the client has open.
In this mode, the server may not be aware of the format of any its In this mode, the server may not be aware of the format of any its
object labels. Indeed, it may service several different security object labels. Indeed, it may service several different security
models at the same time. A client MUST process foreign labels as models at the same time. A client MUST process foreign labels as
discussed in Section 3.4. As with the Guest Mode, this mode's level 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 of trust can be degraded if non-MAC-functional clients have access to
the server. the server.
3.5.3. Guest Mode 3.5.3. Guest Mode
skipping to change at page 10, line 45 skipping to change at page 10, line 45
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 The MAC-Functional client determines if a process request is sent to
the remote server. Upon a successful response from the server, it
The server MUST enforce its security policy over all exported must use its own policies on the object's security labels to
objects, for operations which originate both locally and remotely. determine if the process can be given access. The client SHOULD not
need to be cognizant if the server is either a Limited Server or
Requests from authenticated clients MUST be processed using security fully MAC-Functional.
labels and credentials supplied by the client as if they originated
locally.
As with labeling, the system MUST also take into account any other 3.7.1. Client Enforcement
volatile client security state, such as a change in process security
context via dynamic transition. Access decisions SHOULD also be made
based upon the current client security label accessing the object,
rather than the security label 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
security label changes.
A mechanism MUST exist to allow the client to obtain access, and
labeling decisions from the server for locally cached and delegated
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 The implication here is that if the client holds a delegation on an
object, then it enforces policy to local changes based on the object
label it got from the server. When it tries to commit those changes
to the server, it SHOULD be prepared for the server to reject those
changes based on the policies of the server.
If the server is MAC-Functional and the client is not, the server 3.7.2. Server Enforcement
MUST not accept security labels provided by the client, and only
enforce its policy to exported objects. In the event that the client A MAC-Functional server MUST enforce its security policy over all
is MAC-Functional while the server is not then the client may deny exported objects, for operations which originate both locally and
access or fall back on other methods for providing security labeling. remotely.
Requests from authenticated clients MUST be processed using security
labels and credentials supplied by the client as if they originated
locally.
As with labeling, the system MUST also take into account any other
volatile client security state, such as a change in process security
context via dynamic transition. Access decisions SHOULD also be made
based upon the current client security label accessing the object,
rather than the security label which opened it, if different.
The server SHOULD recall delegation of an object if the object's
security label changes.
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 Labeled NFS
then it is the responsibility of the security system to define the support, then it is the responsibility of the security system to
behavior for existing objects. define the behavior for existing objects.
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 14, line 14 skipping to change at page 14, line 17
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 LNFS MAC security labels for clients which use such labels. The Labeled
protocol would be implemented here solely to enable transport of MAC NFS protocol would be implemented here solely to enable transport of
security labels across the network. It should be noted that in such MAC security labels across the network. It should be noted that in
an environment, overall security cannot be as strongly enforced as such an environment, overall security cannot be as strongly enforced
when the server is also enforcing, and that this scheme is aimed at as when the server is also enforcing, and that this scheme is aimed
allowing MAC-capable clients to function with its MAC security policy at allowing MAC-capable clients to function with its MAC security
enabled rather than perhaps disabling it entirely. policy 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 17, line 12 skipping to change at page 17, line 14
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 5.1. Trust Needed for a Community
Labeled NFS is a transport mechanism for labels, a storage
requirement for labels, and a definition of how to interpret labels.
It defines the responsibilities of the client and the server in the
various permutations of being MAC-Functional. It does not however
dictate in any manner whether assumptions can be made about other
entities in the relationship. For example, it does not define
whether a MAC-Functional client can demand that a MAC-Aware server
only accept requests from other MAC-Functional clients. That is a
policy based in a MAC model and this document does not impose
policies on systems.
As the requirement is a policy, it can be met with the use of a MAC
model. Let L be a LFS which implements the Limited Server mode,
i.e., a MAC-Aware server connected to MAC-Functional clients. Then a
new LFS L' can be created which has the additional policy that the
MAC-Aware server MUST not accept any requests from a non-MAC-
Functional client.
5.2. Guest Modes
When either the client or server is operating in guest mode it is When either the client or server is operating in guest mode it is
important to realize that one side is not enforcing MAC protections. important to realize that one side is not enforcing MAC protections.
Alternate methods are being used to handle the lack of MAC support Alternate methods are being used to handle the lack of MAC support
and care should be taken to identify and mitigate threats from and care should be taken to identify and mitigate threats from
possible tampering outside of these methods. possible tampering outside of these methods.
5.2. MAC-Functional Client Configuration 5.3. MAC-Functional Client Configuration
We defined a MAC model as a access control decision made on a system We defined a MAC model as a access control decision made on a system
which normal users do not have the ability to override policies (see which normal users do not have the ability to override policies (see
Section 1). If the process labels are created solely on the client, Section 1). If the process labels are created solely on the client,
then if a malicious user has sufficient access on that client, the then if a malicious user has sufficient access on that client, the
LNFS model is compromised. Note that this is no different from: Labeled NFS model is compromised. Note that this is no different
from:
o current implementations in which the server uses policies to o current implementations in which the server uses policies to
effectively determine the object label for requests from the effectively determine the object label for requests from the
client, or client, or
o local decisions made on the client by the MAC security system. o local decisions made on the client by the MAC security system.
The server must either explicitly trust the client (as in [7]) or the The server must either explicitly trust the client (as in [7]) or the
MAC model should enforce that users cannot override policies, perhaps MAC model should enforce that users cannot override policies, perhaps
via a externally managed source. via a externally managed source.
skipping to change at page 18, line 36 skipping to change at page 19, line 11
[6] 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>.
[7] Carter, J., "Implementing SELinux Support for NFS", [7] Carter, J., "Implementing SELinux Support for NFS",
<http://www.nsa.gov/research/_files/selinux/papers/nfsv3.pdf>. <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 Labeled
effort. NFS effort.
James Morris, Jarrett Lu, and Stephen Smalley all were key James Morris, Jarrett Lu, and Stephen Smalley all were key
contributors to both early versions of this document and to many contributors to both early versions of this document and to many
conference calls. conference calls.
Kathleen Moriarty provided the use cases for ITAR and Legal Hold/ Kathleen Moriarty provided 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.
 End of changes. 31 change blocks. 
85 lines changed or deleted 112 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/