Internet DRAFT - draft-quigley-nfsv4-labeled
draft-quigley-nfsv4-labeled
NFSv4 D. Quiqley
Internet-Draft Consultant
Intended status: Standards Track J. Morris
Expires: April 28, 2012 Red Hat
J. Lu
Oracle
T. Haynes, Ed.
NetApp
S. Smalley
NSA
October 26, 2011
Labeled NFS
draft-quigley-nfsv4-labeled-04.txt
Abstract
This Internet-Draft describes additions to NFSv4 to support Mandatory
Access Control systems. The current draft describes the mechanism
for transporting a MAC security label using the NFSv4 protocol and
the semantics required for that label. In addition to this it
describes an example system of using this label in a fully MAC aware
environment.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
Quiqley, et al. Expires April 28, 2012 [Page 1]
Internet-Draft labledNFS October 2011
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 28, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Quiqley, et al. Expires April 28, 2012 [Page 2]
Internet-Draft labledNFS October 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. MAC Security Attribute . . . . . . . . . . . . . . . . . . . . 6
3.1. Interpreting FATTR4_SEC_LABEL . . . . . . . . . . . . . . 7
3.2. Delegations . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Permission Checking . . . . . . . . . . . . . . . . . . . 8
3.4. Object Creation . . . . . . . . . . . . . . . . . . . . . 8
3.5. Existing Objects . . . . . . . . . . . . . . . . . . . . . 8
3.6. Label Changes . . . . . . . . . . . . . . . . . . . . . . 9
4. Procedure 16: CB_ATTR_CHANGED - Notify Client that the
File's Attributes Changed . . . . . . . . . . . . . . . . . . 10
5. pNFS Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Discovery of Server LNFS Support . . . . . . . . . . . . . . . 11
7. LNFS Areas of Functionality . . . . . . . . . . . . . . . . . 11
7.1. Client Object Labeling . . . . . . . . . . . . . . . . . . 11
7.2. Client Subject Labeling . . . . . . . . . . . . . . . . . 12
7.3. Client Policy Enforcement . . . . . . . . . . . . . . . . 12
7.4. Server Object Labeling . . . . . . . . . . . . . . . . . . 12
7.5. Server Subject Labeling . . . . . . . . . . . . . . . . . 12
7.6. Server Policy Enforcement . . . . . . . . . . . . . . . . 12
8. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Full MAC labeling support for remotely mounted
filesystems . . . . . . . . . . . . . . . . . . . . . . . 13
8.2. MAC labeling of virtual machine images stored on the
network . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.3. International Traffic in Arms Regulations (ITAR) . . . . . 13
8.4. Legal Hold/eDiscovery . . . . . . . . . . . . . . . . . . 14
8.5. Simple security label storage . . . . . . . . . . . . . . 15
8.6. Diskless Linux . . . . . . . . . . . . . . . . . . . . . . 15
8.7. Multi-Level Security . . . . . . . . . . . . . . . . . . . 15
8.7.1. Policy-Enforcing Client and Server . . . . . . . . . . 16
8.7.2. Policy-Enforcing Client . . . . . . . . . . . . . . . 17
8.7.3. Policy-Enforcing Server . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18
Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Quiqley, et al. Expires April 28, 2012 [Page 3]
Internet-Draft labledNFS October 2011
1. Introduction
Mandatory Access Control (MAC) systems have been mainstreamed in
modern operating systems such as Linux (R), FreeBSD (R), Solaris
(TM), and Windows Vista (R). MAC systems bind security attributes to
subjects (processes) and objects within a system. These attributes
are used with other information in the system to make access control
decisions.
Access control models such as Unix permissions or Access Control
Lists are commonly referred to as Discretionary Access Control (DAC)
models. These systems base their access decisions on user identity
and resource ownership. In contrast MAC models base their access
control decisions on the label on the subject (usually a process) and
the object it wishes to access. These labels may contain user
identity information but usually contain additional information. In
DAC systems users are free to specify the access rules for resources
that they own. MAC models base their security decisions on a system
wide policy established by an administrator or organization which the
users do not have the ability to override. DAC systems offer no real
protection against malicious or flawed software due to each program
running with the full permissions of the user executing it.
Inversely MAC models can confine malicious or flawed software and
usually act at a finer granularity than their DAC counterparts.
People desire to use NFSv4 with these systems. A mechanism is
required to provide security attribute information to NFSv4 clients
and servers. This mechanism has the following requirements:
(1) Clients must be able to convey to the server the security
attribute of the subject making the access request. The server
may provide a mechanism to enforce MAC policy based on the
requesting subject's security attribute.
(2) Server must be able to store and retrieve the security attribute
of exported files as requested by the client.
(3) Server must provide a mechanism for notifying clients of
attribute changes of files on the server.
(4) Clients and Servers must be able to negotiate Label Formats and
provide a mechanism to translate between them as needed.
These four requirements are key to the system with only requirements
(2) and (3) requiring changes to NFSv4. The ability to convey the
security attribute of the subject as described in requirement (1)
falls upon the RPC layer to implement (see [2]). Requirement (4)
allows communication between different MAC implementations. The
Quiqley, et al. Expires April 28, 2012 [Page 4]
Internet-Draft labledNFS October 2011
management of label formats and the translation between them does not
require any support from NFSv4 on a protocol level and is out of the
scope of this document.
The first change necessary is to devise a method for transporting and
storing security label data on NFSv4 file objects. Security labels
have several semantics that are met by NFSv4 recommended attributes
such as the ability to set the label value upon object creation.
Access control on these attributes are done through a combination of
two mechanisms. As with other recommended attributes on file objects
the usual DAC checks (ACLs and permission bits) will be performed to
ensure that proper file ownership is enforced. In addition a MAC
system MAY be employed on the client, server, or both to enforce
additional policy on what subjects may modify security label
information.
The second change is to provide a method for the server to notify the
client that the attribute changed on an open file on the server. If
the file is closed, then during the open attempt, the client will
gather the new attribute value. The server MUST not communicate the
new value of the attribute, the client MUST query it. This
requirement stems from the need for the client to provide sufficient
access rights to the attribute.
The final change necessary is a modification to the RPC layer used in
NFSv4 in the form of a new version of the RPCSEC_GSS [3] framework.
In order for an NFSv4 server to apply MAC checks it must obtain
additional information from the client. Several methods were
explored for performing this and it was decided that the best
approach was to incorporate the ability to make security attribute
assertions through the RPC mechanism. RPCSECGSSv3 [2] outlines a
method to assert additional security information such as security
labels on gss context creation and have that data bound to all RPC
requests that make use of that context.
2. Definitions
Label Format Specifier (LFS): is an identifier used by the client to
establish the syntactic format of the security label and the
semantic meaning of its components. These specifiers exist in a
registry associated with documents describing the format and
semantics of the label.
Label Format Registry: is the IANA registry containing all
registered LFS along with references to the documents that
describe the syntactic format and semantics of the security label.
Quiqley, et al. Expires April 28, 2012 [Page 5]
Internet-Draft labledNFS October 2011
Policy Identifier (PI): is an optional part of the definition of a
Label Format Specifier which allows for clients and server to
identify specific security policies.
Object: is a passive resource within the system that we wish to be
protected. Objects can be entities such as files, directories,
pipes, sockets, and many other system resources relevant to the
protection of the system state.
Subject: A subject is an active entity usually a process which is
requesting access to an object.
Multi-Level Security (MLS): is a traditional model where objects are
given a sensitivity level (Unclassified, Secret, Top Secret, etc)
and a category set [8].
3. MAC Security Attribute
MAC models base access decisions on security attributes bound to
subjects and objects. This information can range from a user
identity for an identity based MAC model, sensitivity levels for
Multi-level security, or a type for Type Enforcement. These models
base their decisions on different criteria but the semantics of the
security attribute remain the same. The semantics required by the
security attributes are listed below:
o Must provide flexibility with respect to MAC model.
o Must provide the ability to atomically set security information
upon object creation
o Must provide the ability to enforce access control decisions both
on the client and the server
o Must not expose an object to either the client or server name
space before its security information has been bound to it.
NFSv4 provides several options for implementing the security
attribute. The first option is to implement the security attribute
as a named attribute. Named attributes provide flexibility since
they are treated as an opaque field but lack a way to atomically set
the attribute on creation. In addition, named attributes themselves
are file system objects which need to be assigned a security
attribute. This raises the question of how to assign security
attributes to the file and directories used to hold the security
attribute for the file in question. The inability to atomically
assign the security attribute on file creation and the necessity to
Quiqley, et al. Expires April 28, 2012 [Page 6]
Internet-Draft labledNFS October 2011
assign security attributes to its sub-components makes named
attributes unacceptable as a method for storing security attributes.
The second option is to implement the security attribute as a
recommended attribute. These attributes have a fixed format and
semantics, which conflicts with the flexible nature of the security
attribute. To resolve this the security attribute consists of two
components. The first component is a LFS as defined in [4] to allow
for interoperability between MAC mechanisms. The second component is
an opaque field which is the actual security attribute data. To
allow for various MAC models NFSv4 should be used solely as a
transport mechanism for the security attribute. It is the
responsibility of the endpoints to consume the security attribute and
make access decisions based on their respective models. In addition,
creation of objects through OPEN and CREATE allows for the security
attribute to be specified upon creation. By providing an atomic
create and set operation for the security attribute it is possible to
enforce the second and fourth requirements. The recommended
attribute FATTR4_SEC_LABEL will be used to satisfy this requirement.
3.1. Interpreting FATTR4_SEC_LABEL
The XDR [5] necessary to implement Labeled NFSv4 is presented in
Figure 1:
const FATTR4_SEC_LABEL = 81;
typedef uint32_t policy4;
struct labelformat_spec4 {
policy4 lfs_lfs;
policy4 lfs_pi;
};
struct sec_label_attr_info {
labelformat_spec4 slai_lfs;
opaque slai_data<>;
};
Figure 1
The FATTR4_SEC_LABEL contains an array of two components with the
first component being an LFS. It serves to provide the receiving end
with the information necessary to translate the security attribute
into a form that is usable by the endpoint. Label Formats assigned
an LFS may optionally choose to include a Policy Identifier field to
allow for complex policy deployments. The LFS and Label Format
Registry are described in detail in [4]. The translation used to
interpret the security attribute is not specified as part of the
Quiqley, et al. Expires April 28, 2012 [Page 7]
Internet-Draft labledNFS October 2011
protocol as it may depend on various factors. The second component
is an opaque section which contains the data of the attribute. This
component is dependent on the MAC model to interpret and enforce.
In particular, it is the responsibility of the LFS specification to
define a maximum size for the opaque section, slai_data<>. When
creating or modifying a label for an object, the client needs to be
guaranteed that the server will accept a label that is sized
correctly. By both client and server being part of a specific MAC
model, the client will be aware of the size.
3.2. Delegations
In the event that a security attribute is changed on the server while
a client holds a delegation on the file, the client should follow the
existing protocol with respect to attribute changes. It should flush
all changes back to the server and relinquish the delegation.
3.3. Permission Checking
It is not feasible to enumerate all possible MAC models and even
levels of protection within a subset of these models. This means
that the NFSv4 client and servers cannot be expected to directly make
access control decisions based on the security attribute. Instead
NFSv4 should defer permission checking on this attribute to the host
system. These checks are performed in addition to existing DAC and
ACL checks outlined in the NFSv4 protocol. Section 8 gives a
specific example of how the security attribute is handled under a
particular MAC model.
3.4. Object Creation
When creating files in NFSv4 the OPEN and CREATE operations are used.
One of the parameters to these operations is an fattr4 structure
containing the attributes the file is to be created with. This
allows NFSv4 to atomically set the security attribute of files upon
creation. When a client is MAC aware it must always provide the
initial security attribute upon file creation. In the event that the
server is the only MAC aware entity in the system it should ignore
the security attribute specified by the client and instead make the
determination itself.
3.5. Existing Objects
Note that under the MAC model, all objects must have labels.
Therefore, if an existing server is upgraded to include LNFS support,
then it is the responsibility of the security system to define the
behavior for existing objects. For example, if the security system
Quiqley, et al. Expires April 28, 2012 [Page 8]
Internet-Draft labledNFS October 2011
is LFS 0, which means the server just stores and returns labels, then
existing files should return labels which are set to an empty value.
3.6. Label Changes
As per the requirements, when a file's security label is modified,
the server must notify all clients which have the file opened of the
change in label. It does so with CB_ATTR_CHANGED. There are
preconditions to making an attribute change imposed by NFSv4 and the
security system might want to impose others. In the process of
meeting these preconditions, the server may chose to either serve the
request in whole or return NFS4ERR_DELAY to the SETATTR operation.
If there are open delegations on the file belonging to client other
than the one making the label change, then the process described in
Section 3.2 must be followed.
As the server is always presented with the subject label from the
client, it does not necessarily need to communicate the fact that the
label has changed to the client. In the cases where the change
outright denies the client access, the client will be able to quickly
determine that there is a new label in effect. It is in cases where
the client may share the same object between multiple subjects or a
security system which is not strictly hierarchical that the
CB_ATTR_CHANGED callback is very useful. It allows the server to
inform the clients that the cached security attribute is now stale.
In the scenario presented in Section 8.5, the clients provide policy
enforcement functionality and the server only provides object
labeling functionality. In order to ensure that policy is enforced
upon a label change in this situation, if client A changes a security
label on a file, then the server MUST inform all clients that have
the file opened that the label has changed via CB_ATTR_CHANGED. Then
the clients MUST retrieve the new label and MUST enforce access via
the new attribute values.
[[Comment.1: Describe a LFS of 0, which will be the means to indicate
such a deployment. In the current LFR, 0 is marked as reserved. If
we use it, then we define the default LFS to be used by a LNFS aware
server. I.e., it enables policy-enforcing clients to work together
in the face of a server that only supports object labeling. Note
that while supporting this system is optional, it will make for a
very good debugging mode during development. I.e., even if a server
does not deploy with another security system, this mode gets your
foot in the door. --TH]]
Quiqley, et al. Expires April 28, 2012 [Page 9]
Internet-Draft labledNFS October 2011
4. Procedure 16: CB_ATTR_CHANGED - Notify Client that the File's
Attributes Changed
4.1. ARGUMENTS
struct CB_ATTR_CHANGED4args {
nfs_fh4 acca_fh;
bitmap4 acca_critical;
bitmap4 acca_info;
};
4.2. RESULTS
struct CB_ATTR_CHANGED4res {
nfsstat4 accr_status;
};
4.3. DESCRIPTION
The CB_ATTR_CHANGED callback operation is used by the server to
indicate to the client that the file's attributes have been modified
on the server. The server does not convey how the attributes have
changed, just that they have been modified. The server can inform
the client about both critical and informational attribute changes in
the bitmask arguments. The client SHOULD query the server about all
attributes set in acca_critical. For all changes reflected in
acca_info, the client can decide whether or not it wants to poll the
server.
The CB_ATTR_CHANGED callback operation with the FATTR4_SEC_LABEL set
in acca_critical is the method used by the server to indicate that
the MAC label for the file referenced by acca_fh has changed. In
many ways, the server does not care about the result returned by the
client.
5. pNFS Considerations
This section examines the issues in deploying LNFS in a pNFS
community of servers.
5.1. MAC Label Checks
The new FATTR4_SEC_LABEL attribute is metadata information and as
such the DS is not aware of the value contained on the MDS.
Fortunately, the NFSv4.1 protocol [6] already has provisions for
doing access level checks from the DS to the MDS. In order for the
DS to validate the subject label presented by the client, it SHOULD
Quiqley, et al. Expires April 28, 2012 [Page 10]
Internet-Draft labledNFS October 2011
utilize this mechanism.
If a file's FATTR4_SEC_LABEL is changed, then the MDS should utilize
CB_ATTR_CHANGED to inform the client of that fact. If the MDS is
maintaining
6. Discovery of Server LNFS Support
The server can easily determine that a client supports LNFS when it
queries for the FATTR4_SEC_LABEL label for an object. Note that it
cannot assume that the presence of RPCSEC_GSSv3 indicates LNFS
support. The client might need to discover which LFS the server
supports.
A server which supports LNFS MUST allow a client with any subject
label to retrieve the FATTR4_SEC_LABEL attribute for the root
filehandle, ROOTFH. The following compound must always succeed as
far as a MAC label check is concerned:
PUTROOTFH, GETATTR {FATTR4_SEC_LABEL}
Note that the server might have imposed a security flavor on the root
that precludes such access. I.e., if the server requires kerberized
access and the client presents a compound with AUTH_SYS, then the
server is allowed to return NFS4ERR_WRONGSEC in this case. But if
the client presents a correct security flavor, then the server MUST
return the FATTR4_SEC_LABEL attribute with the supported LFS filled
in.
7. LNFS Areas of Functionality
LNFS functionality falls into three areas for both clients and
servers: object label functionality, subject label functionality, and
policy enforcement. The three areas of functionality are independent
in the protocol specification, but in practice, clients or servers
that support subject label functionality will typically also support
object label functionality, and servers that support policy
enforcement will typically also support subject and object label
functionality.
7.1. Client Object Labeling
Client object label functionality falls into two areas:
Specifying the MAC security attribute for file creation requests
as described in Section 3.4.
Quiqley, et al. Expires April 28, 2012 [Page 11]
Internet-Draft labledNFS October 2011
Handling label change callbacks from the server as described in
Section 3.6.
7.2. Client Subject Labeling
Client subject label functionality consists of asserting the subject
label for the requesting process on the client to the server. The
security attribute of the subject making the request is transported
at the RPC layer using the mechanism described in RPCSECGSSv3 [2].
7.3. Client Policy Enforcement
Client policy enforcement functionality consists of applying MAC
policy checks based on the subject label of the requesting process on
the client and the object label of the file. If object labeling is
supported by the server, then the client will use the object label
provided by the server for the access decision. If not, then the
client may infer an object label for the file based on other criteria
at its disposal, e.g. based on the server identity, the particular
mount, or a local mapping.
7.4. Server Object Labeling
Server object label functionality falls into two areas:
Storing and returning file labels.
Sending label change callbacks when a label change is performed.
7.5. Server Subject Labeling
Server subject label functionality consists of accepting RPCSEC_GSSv3
label assertions.
7.6. Server Policy Enforcement
Server policy enforcement functionality consists of applying MAC
policy checks based on the subject label of the requesting process on
the client and the object label of the file. If the client and the
server both support subject label functionality, then the subject
label provided by the client will be used for the access decision.
If either the client or the server do not support subject label
functionality, then the server may infer a subject label based on
other criteria at its disposal, e.g. based on the client identity.
If the server supports object label functionality, then the object
label that is stored with the file will be used for the access
decision. If not, then an object label may be inferred from other
criteria at its disposal, e.g. based on the exported filesystem or
Quiqley, et al. Expires April 28, 2012 [Page 12]
Internet-Draft labledNFS October 2011
some local mapping.
8. Use Cases
MAC labeling is meant to allow NFSv4 to be deployed in site
configurable security schemes. The LFS and opaque data scheme allows
for flexibility to meet these different implementations. In this
section, we provide some examples of how NFSv4 could be deployed to
meet existing needs. This is not an exhaustive listing.
8.1. Full MAC labeling support for remotely mounted filesystems
In this case, we assume a local networked environment where the
servers and clients are under common administrative control. All
systems in this network have the same MAC implementation and
semantically identical MAC security labels for objects (i.e. labels
mean the same thing on different systems, even if the policies on
each system may differ to some extent). Clients will be able to
apply fine-grained MAC policy to objects accessed via NFS mounts, and
thus improve the overall consistency of MAC policy application within
this environment.
An example of this case would be where user home directories are
remotely mounted, and fine-grained MAC policy is implemented to
protect, for example, private user data from being read by malicious
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
policy to be implemented and provide the desired protection.
8.2. MAC labeling of virtual machine images stored on the network
Virtualization is now a commonly implemented feature of modern
operating systems, and there is a need to ensure that MAC security
policy is able to to protect virtualized resources. A common
implementation scheme involves storing virtualized guest filesystems
on a networked server, which are then mounted remotely by guests upon
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
remotely mounted filesystem so that its MAC security policy can be
applied.
8.3. International Traffic in Arms Regulations (ITAR)
The International Traffic in Arms Regulations (ITAR) is put forth by
the United States Department of State, Directorate of Defense and
Trade Controls. ITAR places strict requirements on the export and
thus access of defense articles and defense services. Organizations
Quiqley, et al. Expires April 28, 2012 [Page 13]
Internet-Draft labledNFS October 2011
that manage projects with articles and services deemed as within the
scope of ITAR must ensure the regulations are met. The regulations
require an assurance that ITAR information is accessed on a need-to-
know basis, thus requiring strict, centrally managed access controls
on items labeled as ITAR. Additionally, organizations must be able
to prove that the controls were adequately maintained and that
foreign nationals were not permitted access to these defense articles
or service. ITAR control applicability may be dynamic; information
may become subject to ITAR after creation (e.g., when the defense
implications of technology are recognized).
8.4. Legal Hold/eDiscovery
Increased cases of legal holds on electronic sources of information
(ESI) have resulted in organizations taking a pro-active approach to
reduce the scope and thus costs associated with these activities.
ESI Data Maps are increasing in use and require support in operating
systems to strictly manage access controls in the case of a legal
hold. The sizeable quantity of information involved in a legal
discovery request may preclude making a copy of the information to a
separate system that manages the legal hold on the copies; this
results in a need to enforce the legal hold on the original
information.
Organizations are taking steps to map out the sources of information
that are most likely to be placed under a legal hold, these efforts
result in ESI Data Maps. ESI Data Maps specify the Electronic Source
of Information and the requirements for sensitivity and criticality.
In the case of a legal hold, the ESI data map and labels can be used
to ensure the legal hold is properly enforced on the predetermined
set of information. An ESI data map narrows the scope of a legal
hold to the predetermined ESI. The information must then be
protected at a level of security of which the weight and
admissibility of that evidence may be proved in a court of law.
Current systems use application level controls and do not adequately
meet the requirements. Labels may be used in advance when an ESI
data map exercise is conducted with controls being applied at the
time of a hold or labels may be applied to data sets during an
eDiscovery exercise to ensure the data protections are adequate
during the legal hold period.
Note that this use case requires multi-attribute labels, as both
information sensitivity (e.g., to disclosure) and information
criticality (e.g., to continued business operations) need to be
captured.
Quiqley, et al. Expires April 28, 2012 [Page 14]
Internet-Draft labledNFS October 2011
8.5. Simple security label storage
In this case, a mixed and loosely administered network is assumed,
where nodes may be running a variety of operating systems with
different security mechanisms and security policies. It is desired
that network file servers be simply capable of storing and retrieving
MAC security labels for clients which use such labels. The Labeled
NFS protocol would be implemented here solely to enable transport of
MAC security labels across the network. It should be noted that in
such an environment, overall security cannot be as strongly enforced
as in case (a), and that this scheme is aimed at allowing MAC-capable
clients to function with local MAC security policy enabled rather
than perhaps disabling it entirely.
8.6. Diskless Linux
A number of popular operating system distributions depend on a
mandatory access control (MAC) model to implement a kernel-enforced
security policy. Typically, such models assign particular roles to
individual processes, which limit or permit performing certain
operations on a set of files, directories, sockets, or other objects.
While the enforcing of the policy is typically a matter for the
diskless NFS client itself, the filesystem objects in such models
will typically carry MAC labels that are used to define policy on
access. These policies may, for instance, describe privilege
transitions that cannot be replicated using standard NFS ACL based
models.
For instance on a SYSV compatible system, if the 'init' process
spawns a process that attempts to start the 'NetworkManager'
executable, there may be a policy that sets up a role transition if
the 'init' process and 'NetworkManager' file labels match a
particular rule. Without this role transition, the process may find
itself having insufficient privileges to perform its primary job of
configuring network interfaces.
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
use of RPCSEC_GSSv3 for enforcing compliance at the server level is
therefore of limited value. The ability to permanently label files
and have those labels read back by the client is, however, crucial to
the ability to enforce that policy.
8.7. Multi-Level Security
In a MLS system objects are generally assigned a sensitivity level
and a set of compartments. The sensitivity levels within the system
are given an order ranging from lowest to highest classification
Quiqley, et al. Expires April 28, 2012 [Page 15]
Internet-Draft labledNFS October 2011
level. Read access to an object is allowed when the sensitivity
level of the subject "dominates" the object it wants to access. This
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
a super-set of the compartments on the object.
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
directory. The system defines the sensitivity levels as Unclassified
(U), Secret (S), and Top Secret (TS). The directory to be searched
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
Secret.
8.7.1. Policy-Enforcing Client and Server
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
enters the kernel. Before translating the readdir system call into a
request to the NFSv4 server the host operating system will consult
the MAC module to see if the operation is allowed. Since the process
is operating at Secret and the directory to be accessed is labeled
Top Secret the MAC module will deny the request and an error code is
returned to user space.
Consider a second case where instead of running at Secret the process
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
module will allow the request. Now the readdir is translated into
the necessary NFSv4 call to the server. For the RPC request the
client is using the proper credential to assert to the server that
the process is running at Top Secret.
When the server receives the request it extracts the security label
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
allowed to read the contents of the Top Secret directory. Since this
is allowed by the policy then the server will return the appropriate
information back to the client.
In this example the policy on the client and server were both the
same. In the event that they were running different policies a
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.
The server may consider additional information when making its policy
decisions. For example the server could determine that a certain
subnet is only cleared for data up to Secret classification. If that
constraint was in place for the example above the client would still
Quiqley, et al. Expires April 28, 2012 [Page 16]
Internet-Draft labledNFS October 2011
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).
8.7.2. Policy-Enforcing Client
With a policy-enforcing client and a label-unaware server, this
example is identical to the first part of the previous example. A
process on the client labeled Secret wishes to access a Top Secret
directory. As in the previous example, this is denied since Secret
does not dominate Top Secret. If the process were operating at Top
Secret it would pass the local access control check and the NFSv4
operation would proceed as in a normal NFSv4 environment.
8.7.3. Policy-Enforcing Server
With a policy-enforcing server and a label-unaware client, the client
behaves as if it were in a normal NFSv4 environment. Since the
process on the client does not provide a security attribute the
server must define a mechanism for labeling all requests from a
client. Assume that the server is using the same criteria used in
the first example. The server sees the request as coming from a
subnet that is a Secret network. The server determines that all
clients on that subnet will have their requests labeled with 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
NFS4ERR_ACCESS.
9. Security Considerations
This entire document deals with security issues.
Depending on the level of protection the MAC system offers there may
be a requirement to tightly bind the security attribute to the data.
When either the client or the server is label-unaware, it is
important to realize that the other side is not enforcing MAC
protections. Alternate methods might be in use to handle the lack of
MAC support and care should be taken to identify and mitigate threats
from possible tampering outside of these methods.
An example of this is that a policy-enforcing server that modifies
READDIR or LOOKUP results based on the client's subject label might
want to always construct the same subject label for a client which
does not present one. This will prevent a non-LNFS client from
mixing entries in the directory cache.
Quiqley, et al. Expires April 28, 2012 [Page 17]
Internet-Draft labledNFS October 2011
10. IANA Considerations
This section uses terms that are defined in [7].
The LFS and Label Format Registry are described in detail in [4].
11. References
11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", March 1997.
[2] Haynes, T. and N. Williams, "Remote Procedure Call (RPC)
Security Version 3", draft-williams-rpcsecgssv3 (work in
progress), 2011.
[3] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997.
[4] Quigley, D. and J. Lu, "Registry Specification for MAC Security
Label Formats", draft-quigley-label-format-registry (work in
progress), 2011.
[5] Eisler, M., "XDR: External Data Representation Standard",
RFC 4506, May 2006.
[6] Shepler, S., Eisler, M., and D. Noveck, "Network File System
(NFS) Version 4 Minor Version 1 Protocol", RFC 5661,
January 2010.
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
11.2. Informative References
[8] "Section 46.6. Multi-Level Security (MLS) of Deployment Guide:
Deployment, configuration and administration of Red Hat
Enterprise Linux 5, Edition 6", 2011.
Appendix A. Acknowledgments
Kathleen Moriarty provided the use cases for ITAR and Legal Hold/
eDiscovery.
Dan Walsh provided use cases for Secure Virtualization, Sandboxing,
Quiqley, et al. Expires April 28, 2012 [Page 18]
Internet-Draft labledNFS October 2011
and NFS homedir labeling to handle process separation.
Trond Myklebust provided use cases for secure diskless NFS clients.
Appendix B. RFC Editor Notes
[RFC Editor: please remove this section prior to publishing this
document as an RFC]
[RFC Editor: prior to publishing this document as an RFC, please
replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the
RFC number of this document]
Authors' Addresses
David Quigley
Consultant
Email: dpquigl@davequigley.com
James Morris
Red Hat, Inc.
Email: jmorris@namei.org
Jarrett Lu
Oracle
Email: jarrett.lu@oracle.com
Thomas Haynes (editor)
NetApp
9110 E 66th St
Tulsa, OK 74133
USA
Phone: +1 918 307 1415
Email: thomas@netapp.com
Quiqley, et al. Expires April 28, 2012 [Page 19]
Internet-Draft labledNFS October 2011
Stephen Smalley
National Security Agency
Email: sds@tycho.nsa.gov
Quiqley, et al. Expires April 28, 2012 [Page 20]
