--- 1/draft-ietf-nfsv4-labreqs-04.txt 2013-12-02 10:14:26.936847627 -0800 +++ 2/draft-ietf-nfsv4-labreqs-05.txt 2013-12-02 10:14:26.972848467 -0800 @@ -1,245 +1,251 @@ NFSv4 T. Haynes Internet-Draft NetApp -Intended status: Informational August 04, 2013 -Expires: February 5, 2014 +Intended status: Informational December 02, 2013 +Expires: June 05, 2014 Requirements for Labeled NFS - draft-ietf-nfsv4-labreqs-04.txt + draft-ietf-nfsv4-labreqs-05.txt Abstract This memo outlines high-level requirements for the integration of flexible Mandatory Access Control (MAC) functionality into the Network File System (NFS) version 4.2 (NFSv4.2). It describes the level of protections that should be provided over protocol components and the basic structure of the proposed system. The intent here is not to present the protocol changes, but to describe the environment in which they reside. -Status of this Memo +Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on February 5, 2014. + This Internet-Draft will expire on June 05, 2014. Copyright Notice Copyright (c) 2013 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 Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 - 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.2. Security Services . . . . . . . . . . . . . . . . . . . . 6 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 + 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.2. Security Services . . . . . . . . . . . . . . . . . . . . 5 3.3. Label Encoding, Label Format Specifiers, and Label - Checking Authorities . . . . . . . . . . . . . . . . . . . 6 - 3.4. Labeling . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 3.4.1. Client Labeling . . . . . . . . . . . . . . . . . . . 7 - 3.4.2. Server Labeling . . . . . . . . . . . . . . . . . . . 8 - 3.5. Policy Enforcement . . . . . . . . . . . . . . . . . . . . 8 - 3.5.1. Client Enforcement . . . . . . . . . . . . . . . . . . 8 - 3.5.2. Server Enforcement . . . . . . . . . . . . . . . . . . 9 - 3.6. Namespace Access . . . . . . . . . . . . . . . . . . . . . 9 - 3.7. Upgrading Existing Server . . . . . . . . . . . . . . . . 9 - 4. Modes of Operation . . . . . . . . . . . . . . . . . . . . . . 10 - 4.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . . . 10 - 4.2. Limited Server Mode . . . . . . . . . . . . . . . . . . . 11 - 4.3. Guest Mode . . . . . . . . . . . . . . . . . . . . . . . . 11 + Checking Authorities . . . . . . . . . . . . . . . . . . 5 + 3.4. Labeling . . . . . . . . . . . . . . . . . . . . . . . . 6 + 3.4.1. Client Labeling . . . . . . . . . . . . . . . . . . . 6 + 3.4.2. Server Labeling . . . . . . . . . . . . . . . . . . . 7 + 3.5. Policy Enforcement . . . . . . . . . . . . . . . . . . . 7 + 3.5.1. Client Enforcement . . . . . . . . . . . . . . . . . 7 + 3.5.2. Server Enforcement . . . . . . . . . . . . . . . . . 8 + 3.6. Namespace Access . . . . . . . . . . . . . . . . . . . . 8 + 3.7. Upgrading Existing Server . . . . . . . . . . . . . . . . 8 + 4. Modes of Operation . . . . . . . . . . . . . . . . . . . . . 9 + 4.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.2. Limited Server Mode . . . . . . . . . . . . . . . . . . . 10 + 4.3. Guest Mode . . . . . . . . . . . . . . . . . . . . . . . 10 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Full MAC labeling support for remotely mounted - filesystems . . . . . . . . . . . . . . . . . . . . . . . 12 + filesystems . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. MAC labeling of virtual machine images stored on the - network . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 5.3. International Traffic in Arms Regulations (ITAR) . . . . . 12 - 5.4. Legal Hold/eDiscovery . . . . . . . . . . . . . . . . . . 13 - 5.5. Simple security label storage . . . . . . . . . . . . . . 13 - 5.6. Diskless Linux . . . . . . . . . . . . . . . . . . . . . . 14 - 5.7. Multi-Level Security . . . . . . . . . . . . . . . . . . . 14 - 5.7.1. Full Mode - MAC-functional Client and Server . . . . . 15 - 5.7.2. MAC-Functional Client . . . . . . . . . . . . . . . . 15 - 5.7.3. MAC-Functional Server . . . . . . . . . . . . . . . . 16 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 6.1. Trust Needed for a Community . . . . . . . . . . . . . . . 16 - 6.2. Guest Modes . . . . . . . . . . . . . . . . . . . . . . . 17 - 6.3. MAC-Functional Client Configuration . . . . . . . . . . . 17 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 - 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 - 7.2. Informative References . . . . . . . . . . . . . . . . . . 18 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18 - Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 19 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 + network . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 5.3. Simple security label storage . . . . . . . . . . . . . . 11 + 5.4. Diskless Linux . . . . . . . . . . . . . . . . . . . . . 12 + 5.5. Multi-Level Security . . . . . . . . . . . . . . . . . . 12 + 5.5.1. Full Mode - MAC-functional Client and Server . . . . 13 + 5.5.2. MAC-Functional Client . . . . . . . . . . . . . . . . 14 + 5.5.3. MAC-Functional Server . . . . . . . . . . . . . . . . 14 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 7.1. Trust Needed for a Community . . . . . . . . . . . . . . 15 + 7.2. Guest Modes . . . . . . . . . . . . . . . . . . . . . . . 15 + 7.3. MAC-Functional Client Configuration . . . . . . . . . . . 15 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 + 8.2. Informative References . . . . . . . . . . . . . . . . . 16 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 17 + Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 17 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction - Mandatory Access Control (MAC) systems have been mainstreamed in - modern operating systems such as Linux, FreeBSD, and Solaris. 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. + Mandatory Access Control (MAC) ([RFC4949]) systems have been + mainstreamed in modern operating systems such as Linux, FreeBSD, and + Solaris. 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. + users do not have the ability to override. DAC systems offers some + protection against unauthorized users running malicious software. + However, even an authorized user can execute malicious or flawed + software with those programs 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. Besides describing the requirements, this document records the functional requirements for the client imposed by the pre-existing security models on the client. This document may help those outside the NFS community understand those issues. 2. Definitions + Foreign Label: is when a MAC implementation encounters a label in a + format other than it uses for encoding. + Label Format Specifier (LFS): is an identifier used by the client to establish the syntactic format of the security label and the semantic meaning of its components. Label Format Registry: is the IANA registry (see [lfsreg]) containing all registered LFS along with references to the documents that describe the syntactic format and semantics of the security label. - Policy Identifier (PI): is an optional part of the definition of a - Label Format Specifier which allows for clients and server to - identify specific security policies. - - Object: is a passive resource within the system that we wish to be - protected. Objects can be entities such as files, directories, - pipes, sockets, and many other system resources relevant to the - protection of the system state. - - Subject: is an active entity, usually a process, which is requesting - access to an object. - MAC-Aware: is a server which can transmit and store object labels. MAC-Functional: is a client or server which is Labeled NFS enabled. Such a system can interpret labels and apply policies based on the security system. Multi-Level Security (MLS): is a traditional model where objects are given a sensitivity level (Unclassified, Secret, Top Secret, etc) and a category set [RH_MLS]. + Object: is a passive resource within the system that we wish to be + protected. Objects can be entities such as files, directories, + pipes, sockets, and many other system resources relevant to the + protection of the system state. + + Policy Identifier (PI): is an optional part of the definition of a + Label Format Specifier which allows for clients and server to + identify specific security policies. + + Subject: is an active entity, usually a process, which is requesting + access to an object. + 2.1. Requirements Language 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 [RFC2119]. 3. Requirements The following initial requirements have been gathered from users, developers, and from previous development efforts in this area such as DTOS [DTOS] and NSA's experimental NFSv3 enhancements [SENFSV3]. 3.1. General 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. + (1) Clients MUST be able to convey to the server the client's + priveleges, i.e., the subject, for making the access request. The + server may provide a mechanism to enforce MAC policy based on the + requesting client's priveleges. (2) Servers MUST be able to store and retrieve the security attribute of exported files as requested by the client. (3) Servers 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. 3.2. Security Services - Labeled NFS SHOULD support that the following security services are - provided for all NFSv4.2 messaging. These services may be provided - by lower layers even if NFS has to be aware of and leverage them: + Labeled NFS or the underlying system on which the Labeled NFS + operates MUST provide the following security services for all NFSv4.2 + messaging + o Authentication o Integrity o Privacy Mechanisms and algorithms used in the provision of security services MUST be configurable, so that appropriate levels of protection may be flexibly specified per mandatory security policy. - Strong mutual authentication will be required between the server and - the client for Full Mode operation Section 4.1. + Strong mutual authentication is required between the server and the + client for Full Mode operation Section 4.1. - MAC security labels and any related security state SHOULD always be + MAC security labels and any related security state MUST always be protected by these security services when transferred over the - network; as SHOULD the binding of labels and state to associated + network; as MUST the binding of labels and state to associated objects and subjects. Labeled NFS SHOULD support authentication on a context granularity so that different contexts running on a client can use different cryptographic keys and facilities. 3.3. Label Encoding, Label Format Specifiers, and Label Checking Authorities Encoding of MAC labels and attributes passed over the network MUST be specified in a complete and unambiguous manner while maintaining the flexibility of MAC implementations. To accomplish this the labels - MUST consist of an opaque component bound with a Label Format + MUST consist of a format-specific component bound with a Label Format Specifier (LFS). The LFS component provides a mechanism for identifying the structure and semantics of the opaque component. Meanwhile, the opaque component is the security label which will be interpreted by the MAC models. - MAC models base access decisions on security attributes bound to - subjects and objects. With a given MAC model, all systems have - semantically coherent labeling - a security label MUST always mean - exactly the same thing on every system. While this may not be - necessary for simple MAC models it is recommended that most label - formats assigned an LFS incorporate this concept into their label - format. + MAC models base access decisions on security attributes priveleges + bound to subjects and objects, respectively. With a given MAC model, + all systems have semantically coherent labeling - a security label + MUST always mean exactly the same thing on every system. While this + may not be necessary for simple MAC models it is recommended that + most label formats assigned an LFS incorporate semantically coherent + labeling into their label format. Labeled NFS SHOULD define an initial negotiation scheme with the primary aims of simplicity and completeness. This is to facilitate practical deployment of systems without being weighed down by complex and over-generalized global schemes. Future extensibility SHOULD also be taken into consideration. Labeled NFS MUST provide a means for servers and clients to identify their LFS for the purposes of authorization, security service selection, and security label interpretation. @@ -301,22 +307,22 @@ security labels on all exported file system objects where possible. This includes cases where only in-core and/or read-only security labels are available at the server for any of its exported file systems. 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 to reject the label specified by the client due to restrictions in 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. - The server is allowed to translate the label but SHOULD NOT change - the semantic meaning of the label. + The server is allowed to translate the label but MUST NOT change the + semantic meaning of the label. 3.5. Policy Enforcement The MAC-Functional client determines if a process request is sent to the remote server. Upon a successful response from the server, it must use its own policies on the object's security labels to 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 fully MAC-Functional. @@ -499,87 +507,35 @@ 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 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. -5.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 - that manage projects with articles and services deemed as within the - scope of ITAR must ensure the regulations are met. The regulations - require an assurance that ITAR information is accessed on a need-to- - know basis, thus requiring strict, centrally managed access controls - on items labeled as ITAR. Additionally, organizations must be able - to prove that the controls were adequately maintained and that - foreign nationals were not permitted access to these defense articles - or service. ITAR control applicability may be dynamic; information - may become subject to ITAR after creation (e.g., when the defense - implications of technology are recognized). - -5.4. Legal Hold/eDiscovery - - Increased cases of legal holds on electronic sources of information - (ESI) have resulted in organizations taking a pro-active approach to - reduce the scope and thus costs associated with these activities. - ESI Data Maps are increasing in use and require support in operating - systems to strictly manage access controls in the case of a legal - hold. The sizeable quantity of information involved in a legal - discovery request may preclude making a copy of the information to a - separate system that manages the legal hold on the copies; this - results in a need to enforce the legal hold on the original - information. - - Organizations are taking steps to map out the sources of information - that are most likely to be placed under a legal hold, these efforts - result in ESI Data Maps. ESI Data Maps specify the Electronic Source - of Information and the requirements for sensitivity and criticality. - In the case of a legal hold, the ESI data map and labels can be used - to ensure the legal hold is properly enforced on the predetermined - set of information. An ESI data map narrows the scope of a legal - hold to the predetermined ESI. The information must then be - protected at a level of security of which the weight and - admissibility of that evidence may be proved in a court of law. - Current systems use application level controls and do not adequately - meet the requirements. Labels may be used in advance when an ESI - data map exercise is conducted with controls being applied at the - time of a hold or labels may be applied to data sets during an - eDiscovery exercise to ensure the data protections are adequate - during the legal hold period. - - Note that this use case requires multi-attribute labels, as both - information sensitivity (e.g., to disclosure) and information - criticality (e.g., to continued business operations) need to be - captured. - -5.5. Simple security label storage +5.3. 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 when the server is also enforcing, and that this scheme is aimed at allowing MAC-capable clients to function with its MAC security policy enabled rather than perhaps disabling it entirely. -5.6. Diskless Linux +5.4. Diskless Linux A number of popular operating system distributions depend on a 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 @@ -594,40 +550,39 @@ 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 ([rpcsecgssv3]) 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. -5.7. Multi-Level Security - +5.5. 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 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. -5.7.1. Full Mode - MAC-functional Client and Server +5.5.1. Full Mode - MAC-functional Client and Server In the first part of this example a process on the client is running 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.2 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. @@ -650,97 +605,102 @@ 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 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). -5.7.2. MAC-Functional Client +5.5.2. MAC-Functional Client In these scenarios, the server is either non-MAC-Aware or MAC-Aware. 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 one. I.e., does it utilize the approach presented in Section 4.3 or does it allow the MAC-Aware server to return labels? With a client that is MAC-Functional and using the example in the previous section, the result should be the same. The one difference is that all decisions are made on the client. -5.7.2.1. MAC-Aware Server +5.5.2.1. MAC-Aware Server A process on the client labeled Secret wishes to access a directory labeled Top Secret on the server. This is denied since Secret does not dominate Top Secret. Note that there will be NFSv4.2 operations issued that return an object label for the client to process. Note that in this scenario, all of the clients must be MAC- Functional. A single client which does not do its access control checks would violate the model. -5.7.2.2. Non-MAC-Aware Server +5.5.2.2. Non-MAC-Aware Server A process on the client labeled Secret wishes to access a directory which the client's policies label as Top Secret on the server. This is denied since Secret does not dominate Top Secret. Note that there will not be NFSv4.2 operations issued. If the process had instead a Top Secret process label, the client would issue NFSv4.2 operations to access the directory on the server. -5.7.3. MAC-Functional Server +5.5.3. MAC-Functional Server With a MAC-Functional server and a client which is not, the client behaves as if it were in a normal NFSv4.2 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. -6. Security Considerations +6. IANA Considerations -6.1. Trust Needed for a Community + This document has no actions for IANA. + +7. Security Considerations + +7.1. Trust Needed for a Community Labeled NFS is a transport mechanism for labels, a storage 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. -6.2. Guest Modes +7.2. Guest Modes When either the client or server is operating in guest mode it is important to realize that one side is not enforcing MAC protections. Alternate methods are being used to handle the lack of MAC support and care should be taken to identify and mitigate threats from possible tampering outside of these methods. -6.3. MAC-Functional Client Configuration +7.3. MAC-Functional Client Configuration We defined a MAC model as a access control decision made on a system which normal users do not have the ability to override policies (see Section 1). If the process labels are created solely on the client, then if a malicious user has sufficient access on that client, the Labeled NFS model is compromised. Note that this is no different from: o current implementations in which the server uses policies to effectively determine the object label for requests from the @@ -748,65 +708,68 @@ o local decisions made on the client by the MAC security system. The server must either explicitly trust the client (as in [SENFSV3]) or the MAC model should enforce that users cannot override policies, perhaps via a externally managed source. Once the labels leave the client, they can be protected by the transport mechanism as described in Section 3.2. -7. References -7.1. Normative References +8. References + +8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. -7.2. Informative References +8.2. Informative References [DTOS] Smalley, S., "The Distributed Trusted Operating System - (DTOS) Home Page", . + (DTOS) Home Page ", December 2000, . [I-D.ietf-nfsv4-minorversion2] - Haynes, T. and D. Noveck, "NFS Version 4 Minor Version 2", - draft-ietf-nfsv4-minorversion2-19 (Work In Progress), - March 2013. + Haynes, T., "NFS Version 4 Minor Version 2", draft-ietf- + nfsv4-minorversion2-21 (Work In Progress), November 2013. + + [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", + August 2007. [RH_MLS] "Section 46.6. Multi-Level Security (MLS) of Deployment Guide: Deployment, configuration and administration of Red Hat Enterprise Linux 5, Edition 6", 2011. - [SENFSV3] Carter, J., "Implementing SELinux Support for NFS", . + [SENFSV3] Carter, J., "Implementing SELinux Support for NFS", , + . [lfsreg] Quigley, D. and J. Lu, "Registry Specification for MAC - Security Label Formats", - draft-quigley-label-format-registry (work in progress), - 2011. + Security Label Formats", draft-quigley-label-format- + registry (work in progress), 2011. [rpcsecgssv3] - Haynes, T. and N. Williams, "Remote Procedure Call (RPC) - Security Version 3", draft-williams-rpcsecgssv3 (work in - progress), 2011. + Adamson, W. and N. Williams, "Remote Procedure Call (RPC) + Security Version 3", draft-ietf-nfsv4-rpcsec-gssv3-05 + (Work In Progress), October 2013. Appendix A. Acknowledgments David Quigley was the early energy in motivating the entire Labeled NFS effort. James Morris, Jarrett Lu, and Stephen Smalley all were key contributors to both early versions of this document and to many conference calls. - Kathleen Moriarty provided the use cases for ITAR and Legal Hold/ - eDiscovery. + Kathleen Moriarty provided use cases for earlier versions of the + draft. Dan Walsh provided use cases for Secure Virtualization, Sandboxing, and NFS homedir labeling to handle process separation. Trond Myklebust provided use cases for secure diskless NFS clients. Both Nico Williams and Bryce Nordgren challenged assumptions during the review processes. Appendix B. RFC Editor Notes