--- 1/draft-ietf-nfsv4-labreqs-02.txt 2012-05-28 13:14:40.289758371 +0200 +++ 2/draft-ietf-nfsv4-labreqs-03.txt 2012-05-28 13:14:40.325758769 +0200 @@ -1,18 +1,18 @@ NFSv4 T. Haynes, Ed. Internet-Draft NetApp -Intended status: Standards Track May 11, 2012 -Expires: November 12, 2012 +Intended status: Standards Track May 18, 2012 +Expires: November 19, 2012 Requirements for Labeled NFS - draft-ietf-nfsv4-labreqs-02.txt + draft-ietf-nfsv4-labreqs-03.txt Abstract This Internet-Draft outlines high-level requirements for the integration of flexible Mandatory Access Control (MAC) functionality into NFSv4.2. It describes the level of protections that should be provided over protocol components and the basic structure of the proposed system. It also gives a brief explanation of what kinds of protections MAC systems offer. @@ -30,21 +30,21 @@ 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 November 12, 2012. + This Internet-Draft will expire on November 19, 2012. Copyright Notice Copyright (c) 2012 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 @@ -77,45 +77,46 @@ 3.4. Label Encoding, Label Format Specifiers, and Label Checking Authorities . . . . . . . . . . . . . . . . . . . 7 3.5. Modes of Operation . . . . . . . . . . . . . . . . . . . . 8 3.5.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 8 3.5.2. Limited Server Mode . . . . . . . . . . . . . . . . . 9 3.5.3. Guest Mode . . . . . . . . . . . . . . . . . . . . . . 9 3.6. Labeling . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.6.1. Client Labeling . . . . . . . . . . . . . . . . . . . 10 3.6.2. Server Labeling . . . . . . . . . . . . . . . . . . . 10 3.7. Policy Enforcement . . . . . . . . . . . . . . . . . . . . 10 - 3.7.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 10 - 3.7.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . . 11 + 3.7.1. Client Enforcement . . . . . . . . . . . . . . . . . . 11 + 3.7.2. Server Enforcement . . . . . . . . . . . . . . . . . . 11 3.8. Namespace Access . . . . . . . . . . . . . . . . . . . . . 11 3.9. Upgrading Existing Server . . . . . . . . . . . . . . . . 12 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Full MAC labeling support for remotely mounted filesystems . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. MAC labeling of virtual machine images stored on the network . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. International Traffic in Arms Regulations (ITAR) . . . . . 13 4.4. Legal Hold/eDiscovery . . . . . . . . . . . . . . . . . . 13 4.5. Simple security label storage . . . . . . . . . . . . . . 14 4.6. Diskless Linux . . . . . . . . . . . . . . . . . . . . . . 14 4.7. Multi-Level Security . . . . . . . . . . . . . . . . . . . 15 4.7.1. Full Mode - MAC-functional Client and Server . . . . . 15 4.7.2. MAC-Functional Client . . . . . . . . . . . . . . . . 16 4.7.3. MAC-Functional Server . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 - 5.1. Guest Modes . . . . . . . . . . . . . . . . . . . . . . . 17 - 5.2. MAC-Functional Client Configuration . . . . . . . . . . . 17 - 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 5.1. Trust Needed for a Community . . . . . . . . . . . . . . . 17 + 5.2. Guest Modes . . . . . . . . . . . . . . . . . . . . . . . 17 + 5.3. MAC-Functional Client Configuration . . . . . . . . . . . 17 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 7.2. Informative References . . . . . . . . . . . . . . . . . . 18 - Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18 + Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 19 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction Mandatory Access Control (MAC) systems have been mainstreamed in modern operating systems such as Linux (R), FreeBSD (R), and Solaris (TM). 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. @@ -170,89 +171,89 @@ 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 LNFS enabled. Such a - system can interpret labels and apply policies based on the + 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 [5]. 3. Requirements The following initial requirements have been gathered from users, developers, and from previous development efforts in this area such as DTOS [6] and NSA's experimental NFSv3 enhancements [7]. 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 access controls. - LNFS MUST be designed and developed to facilitate interoperability - between different LNFS implementations. + Labeled NFS MUST be designed and developed to facilitate + interoperability between different Labeled NFS implementations. - LNFS modifications to standard NFSv4.2 [3] implementations MUST not - adversely impact any existing interoperability of those + Labeled NFS modifications to standard NFSv4.2 [3] implementations + MUST not adversely impact any existing interoperability of those implementations. 3.2. Performance & Scalability - Security mechanisms often impact on system performance. LNFS SHOULD - be designed and implemented in a way which avoids significant + Security mechanisms often impact on system performance. Labeled NFS + SHOULD be designed and implemented in a way which avoids significant performance impact where possible. - As NFSv4.2 is designed for large-scale distributed networking, LNFS - SHOULD also be capable of scaling in a similar manner to underlying - implementations where possible. + As NFSv4.2 is designed for large-scale distributed networking, + Labeled NFS SHOULD also be capable of scaling in a similar manner to + underlying implementations where possible. - LNFS SHOULD respond in a robust manner to system and network outages - associated with typical enterprise and Internet environments. At the - very least, LNFS SHOULD always operate in a fail-safe manner, so that - service disruptions do not cause or facilitate security - vulnerabilities. + Labeled NFS SHOULD respond in a robust manner to system and network + outages associated with typical enterprise and Internet environments. + At the very least, Labeled NFS SHOULD always operate in a fail-safe + manner, so that service disruptions do not cause or facilitate + security vulnerabilities. 3.3. Security Services - LNFS SHOULD ensure 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 SHOULD ensure 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: 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 3.5.1. MAC security labels and any related security state SHOULD always be protected by these security services when transferred over the network; as SHOULD the binding of labels and state to associated objects and subjects. - LNFS SHOULD support authentication on a context granularity so that - different contexts running on a client can use different + 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.4. 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 Specifier (LFS). The LFS component provides a mechanism for @@ -261,23 +262,23 @@ 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. - LNFS MUST provide a means for servers and clients to identify their - LFS for the purposes of authorization, security service selection, - and security label interpretation. + 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. A negotiation scheme SHOULD be provided, allowing systems from different label formats to agree on how they will interpret or translate each others labels. Multiple concurrent agreements may be current between a server and a client. All security labels and related security state transferred across the network MUST be tagged with a valid LFS. If the LFS supported on a system changes, it SHOULD renegotiate @@ -286,51 +287,51 @@ 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 label or state. 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 LFS negotiation is supported by the client and the server, the server SHOULD negotiate a new, concurrent agreement with the client, acting on behalf of the externally located source of the files. - LNFS 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 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. 3.5. Modes of Operation - In a LNFS client and server interaction, we can describe three modes - of operation: + In a Labeled NFS client and server interaction, we can describe three + modes of operation: 1. Full 2. Limited Server 3. Guest These modes arise from the level of MAC functionality in the clients and servers. The clients can be non-MAC-Functional and MAC- Functional. The servers can be non-MAC-Functional, MAC-Aware, and MAC-Functional. A MAC-Functional client MUST be able to determine the level of MAC functionality in the server. Likewise, a MAC-Functional server MUST be able to determine whether or not a client is MAC-Functional. 3.5.1. Full Mode The server and the client have mutually recognized MAC functionality - enabled, and full LNFS functionality is extended over the network - between both client and server. + enabled, and full Labeled NFS functionality is extended over the + network between both client and server. An example of an operation in full mode is as follows. On the initial lookup, the client requests access to an object on the server. It sends its process security context over to the server. The server checks all relevant policies to determine if that process context from that client is allowed to access the resource. Once this has succeeded the object with its associated security information is released to the client. Once the client receives the object it determines if its policies allow the process running on the client access to the object. @@ -347,21 +348,21 @@ everything succeeds. 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 ability to return security information. 3.5.2. Limited Server Mode The server is MAC-Aware and the clients are MAC-Functional. The server can store and transmit labels. It cannot enforce labels. The - server SHOULD inform clients when an object label changes for a file + server MUST inform clients when an object label changes for a file the client has open. In this mode, the server may not be aware of the format of any its object labels. Indeed, it may service several different security models at the same time. A client MUST process foreign labels as discussed in Section 3.4. As with the Guest Mode, this mode's level of trust can be degraded if non-MAC-functional clients have access to the server. 3.5.3. Guest Mode @@ -426,80 +427,85 @@ 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. 3.7. Policy Enforcement -3.7.1. Full Mode - - The server MUST enforce its security policy over all exported - objects, for operations which originate both locally and remotely. - - Requests from authenticated clients MUST be processed using security - labels and credentials supplied by the client as if they originated - locally. + 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. - 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. +3.7.1. Client Enforcement The client MUST apply its own policy to remotely located objects, using security labels for the objects obtained from the server. It MUST be possible to configure the maximum length of time a client may cache state regarding remote labels before re-validating that state 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 state back to the server. The server MUST ensure that any flushed state received is consistent with current policy before committing it to stable storage. Any local security state associated with cached or delegated objects MUST also be flushed back to the server when any other state of the 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 - MUST not accept security labels provided by the client, and only - enforce its policy to exported objects. In the event that the client - is MAC-Functional while the server is not then the client may deny - access or fall back on other methods for providing security labeling. +3.7.2. Server Enforcement + + A MAC-Functional server MUST enforce its security policy over all + exported objects, for operations which originate both locally and + 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 The server SHOULD provide a means to authorize selective access to the exported file system namespace based upon client credentials and according to security policy. This is a common requirement of MLS-enabled systems, which often need to present selective views of namespaces based upon the clearances of the subjects. 3.9. Upgrading Existing Server 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. + Therefore, if an existing server is upgraded to include Labeled NFS + support, then it is the responsibility of the security system to + define the behavior for existing objects. 4. Use Cases MAC labeling is meant to allow NFSv4.2 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.2 could be deployed to meet existing needs. This is not an exhaustive listing. 4.1. Full MAC labeling support for remotely mounted filesystems @@ -584,27 +590,27 @@ information sensitivity (e.g., to disclosure) and information criticality (e.g., to continued business operations) need to be captured. 4.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 LNFS - 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. + 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. 4.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 @@ -725,35 +731,56 @@ 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. 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 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. -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 which normal users do not have the ability to override policies (see Section 1). If the process labels are created solely on the client, then if a malicious user has sufficient access on that client, the - LNFS model is compromised. Note that this is no different from: + 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 client, or o local decisions made on the client by the MAC security system. The server must either explicitly trust the client (as in [7]) or the MAC model should enforce that users cannot override policies, perhaps via a externally managed source. @@ -793,22 +821,22 @@ [6] Smalley, S., "The Distributed Trusted Operating System (DTOS) Home Page", . [7] Carter, J., "Implementing SELinux Support for NFS", . Appendix A. Acknowledgments - David Quigley was the early energy in motivating the entire LNFS - effort. + 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. Dan Walsh provided use cases for Secure Virtualization, Sandboxing, and NFS homedir labeling to handle process separation.