Network Working Group D. Quigley Internet-Draft Intended status: Standards Track J. Morris Expires: September 15, 2011 Red Hat, Inc. J. Lu Sun Microsystems March 14, 2011 Labeled NFSv4 Impact Study draft-quigley-nfsv4-lnfs-impact-01.txt Abstract To consider the Labeled NFS work for addition to the NFSv4 working group charter the working group has requested an impact document be written for the work. This document describes the impact, usecases, customers, and scope of the work to be performed. 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 September 15, 2011. 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 Quigley, et al. Expires September 15, 2011 [Page 1] Internet-Draft Labeled NFSv4 Impact Study March 2011 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Protocol Impact . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Usecases . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Full MAC labeling support for remotely mounted filesystems . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. MAC labeling of virtual machine images stored on the network . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. Simple security label storage . . . . . . . . . . . . . . . 4 2.4. Regulatory Compliance . . . . . . . . . . . . . . . . . . . 5 3. Scope of Work . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Quigley, et al. Expires September 15, 2011 [Page 2] Internet-Draft Labeled NFSv4 Impact Study March 2011 1. Protocol Impact Labeled NFS makes relatively few modifications to NFSv4 and its supporting components. These changes consist of two components one existing in the NFSv4 protocol and the other in the RPCSECGSS framework employed by NFSv4. The first component is 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. Named attributes were explored to handle this functionality however as they lack the required semantics that are present in recommended attributes that method was abandoned. 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 Mandatory Access Control (MAC) system MAY be employed on the client, server, or both to enforce additional policy on what subjects may modify security label information. Recommended attributes are straight forward to add to NFSv4 requiring just a new number and a description of the attribute semantics. The second component is a modification to the RPC layer used in NFSv4 in the form of a new version of the RPCSECGSS framework. In order for an NFS 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. The RPCSECGSSv3 document published by Nico Williams 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. As this is a modification for the RPC layer for NFSv4 this work falls under the working groups domain. Luckily due to how RPCSECGSSv3 is designed no changes to prior versions of RPCSECGSS are necessary. Version 3 can be built on top of an existing version 1 or two implementation. 2. Usecases XXX:Use cases, customers. Option feature sounds like only path. So, who would implement it? For exactly what use? One thing that would help here is two other authors besides yourself producing the informational spec. Quigley, et al. Expires September 15, 2011 [Page 3] Internet-Draft Labeled NFSv4 Impact Study March 2011 2.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. 2.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. 2.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 can not 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. Quigley, et al. Expires September 15, 2011 [Page 4] Internet-Draft Labeled NFSv4 Impact Study March 2011 2.4. Regulatory Compliance XXX:Insert text here 3. Scope of Work XXX:Scope: What does it depend on? What are the external dependencies of the opaque encapsulated data? Labeled NFS consists of four documents three of which fall under the jurisdiction of the NFSv4 working group. These documents consist of a requirements document, a specification document for the MAC recommended attribute, and a document outlining RPCSECGSSv3 which enables security information assertions from the client. The last document which falls under the security area but is required for Labeled NFS is the label format specifier document which provides a method for enabling the use various MAC mechanisms by the MAC recommended attribute and RPCSECGSSv3. The requirements document for Labeled NFS has been published as draft-quigley-nfsv4-sec-label-requirements-01. This document describes the problem space that Labeled NFS is addressing, requirements for security labeling and several operating modes that make use of the new security label data. This document has gone through two public revisions so far and will continue to be revised as the need arises. The MAC recommended attribute specification document describes the protocol changes to NFSv4 in the form of a new optional to implement recommended attribute. This document is currently published as draft-quigley-nfsv4-sec-label-00. The initial round of review for this document has taken place and suggestions have been incorporated into the next version of the document. If new requirement manifest through the design process they will be incorporated into this document. The RPCSEC_GSS version 3 specification document is currently published as draft-williams-rpcsecgssv3-00 and is a normative reference for the work. This new version adds the ability for clients supporting Labeled NFSv4 to provide security attributes for a Labeled NFS server to use in access control decisions. For example when a Labeled NFS client and server pair both running SELinux make a filesystem access the following happens. Using RPCSEC_GSS v3 the client will assert the security label of the process issuing the request. Once received the server will use that label to check it's local policy against the remote application. This functionality is useful for building more robust systems using Labeled NFS. While the Quigley, et al. Expires September 15, 2011 [Page 5] Internet-Draft Labeled NFSv4 Impact Study March 2011 modifications to the NFSv4 protocol do not require it this functionality for label storage it is listed as a requirement for Labeled NFS. The MAC recommended attribute document makes reference to a Label Format Specifier(LFS) that is used to determine the format of security labels being transmitted. This document will exist in the security area as it is a document describing the use of security labels in general. The document will contain how label formats should be specified and registered, who is responsible for the registry, and general semantics of their use. While this document is a normative reference for the work individual labels formals should not be. If one particular label format is chosen for interoperability purposes it will be added as a normative reference to both the MAC attribute specification and RPCSECGSSv3 documents. 4. Security Considerations XXX:I don't know if we need this section but it seems to be required 5. Normative References [I-D.ietf-nfsv4-minorversion1] Shepler, S., Eisler, M., and D. Noveck, "NFS Version 4 Minor Version 1", draft-ietf-nfsv4-minorversion1-29 (work in progress), December 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses David P. Quigley Email: dpquigl@davequigley.com James Morris Red Hat, Inc. Email: jmorris@namei.org Quigley, et al. Expires September 15, 2011 [Page 6] Internet-Draft Labeled NFSv4 Impact Study March 2011 Jarrett Lu Sun Microsystems Email: jarrett.lu@sun.com Quigley, et al. Expires September 15, 2011 [Page 7]