NFSv4 D. Quiqley Internet-Draft Consultant Intended status: Standards Track J. Morris Expires: December 24, 2011 Red Hat J. Lu Oracle T. Haynes, Ed. NetApp June 22, 2011 Labeled NFS draft-quigley-nfsv4-labeled-03.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. The list of Internet-Draft Shadow Directories can be accessed at Quiqley, et al. Expires December 24, 2011 [Page 1] Internet-Draft labledNFS June 2011 http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 24, 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 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 December 24, 2011 [Page 2] Internet-Draft labledNFS June 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 . . . . . . . . . . . . . . . . . . . . . 9 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. MAC Security NFS Modes of Operation . . . . . . . . . . . . . 11 7.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1.1. Initial Labeling and Translation . . . . . . . . . . . 12 7.1.2. Policy Enforcement . . . . . . . . . . . . . . . . . . 12 7.2. Smart Client Mode . . . . . . . . . . . . . . . . . . . . 13 7.2.1. Initial Labeling and Translation . . . . . . . . . . . 13 7.2.2. Policy Enforcement . . . . . . . . . . . . . . . . . . 13 7.3. Smart Server Mode . . . . . . . . . . . . . . . . . . . . 14 7.3.1. Initial Labeling and Translation . . . . . . . . . . . 14 7.3.2. Policy Enforcement . . . . . . . . . . . . . . . . . . 14 8. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Full MAC labeling support for remotely mounted filesystems . . . . . . . . . . . . . . . . . . . . . . . 15 8.2. MAC labeling of virtual machine images stored on the network . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.3. International Traffic in Arms Regulations (ITAR) . . . . . 15 8.4. Legal Hold/eDiscovery . . . . . . . . . . . . . . . . . . 16 8.5. Simple security label storage . . . . . . . . . . . . . . 16 8.6. Diskless Linux . . . . . . . . . . . . . . . . . . . . . . 17 8.7. Multi-Level Security . . . . . . . . . . . . . . . . . . . 17 8.7.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 18 8.7.2. Smart Client Mode . . . . . . . . . . . . . . . . . . 18 8.7.3. Smart Server Mode . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . . 20 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Quiqley, et al. Expires December 24, 2011 [Page 3] Internet-Draft labledNFS June 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 Domains of Interpretation (DOI) 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) Quiqley, et al. Expires December 24, 2011 [Page 4] Internet-Draft labledNFS June 2011 allows communication between different MAC implementations. The management of label formats, DOIs, 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. Quiqley, et al. Expires December 24, 2011 [Page 5] Internet-Draft labledNFS June 2011 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. 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. Domain of Interpretation (DOI): represents an administrative security boundary, where all systems within the DOI have semantically coherent labeling. That is, a security attribute must always mean exactly the same thing anywhere within the DOI. 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 Quiqley, et al. Expires December 24, 2011 [Page 6] Internet-Draft labledNFS June 2011 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 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 Quiqley, et al. Expires December 24, 2011 [Page 7] Internet-Draft labledNFS June 2011 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 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 7 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 Quiqley, et al. Expires December 24, 2011 [Page 8] Internet-Draft labledNFS June 2011 determination itself. A more in depth explanation can be found in Section 7. 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 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 are smart and the server has a very simple security system which just stores the labels. In this system, the MAC label check always allows access, regardless of the subject label. The way in which MAC labels are enforced is by the smart client. So 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 Quiqley, et al. Expires December 24, 2011 [Page 9] Internet-Draft labledNFS June 2011 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 lets smart clients work together in the face of a dumb server. Note that will 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]] 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 Quiqley, et al. Expires December 24, 2011 [Page 10] Internet-Draft labledNFS June 2011 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 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. MAC Security NFS Modes of Operation A system using Labeled NFS may operate in three modes. The first mode provides the most protection and is called "full mode". In this mode both the client and server implement a MAC model allowing each end to make an access control decision. The remaining two modes are variations on each other and are called "smart client" and "smart server" modes. In these modes one end of the connection is not Quiqley, et al. Expires December 24, 2011 [Page 11] Internet-Draft labledNFS June 2011 implementing a MAC model and because of this these operating modes offer less protection than full mode. 7.1. Full Mode Full mode environments consist of MAC aware NFSv4 servers and clients and may be composed of mixed MAC models and policies. The system requires that both the client and server have an opportunity to perform an access control check based on all relevant information within the network. The file object security attribute is provided using the mechanism described in Section 3. The security attribute of the subject making the request is transported at the RPC layer using the mechanism described in RPCSECGSSv3 [2]. 7.1.1. Initial Labeling and Translation The ability to create a file is an action that a MAC model may wish to mediate. The client is given the responsibility to determine the initial security attribute to be placed on a file. This allows the client to make a decision as to the acceptable security attributes to create a file with before sending the request to the server. Once the server receives the creation request from the client it may choose to evaluate if the security attribute is acceptable. Security attributes on the client and server may vary based on MAC model and policy. To handle this the security attribute field has an LFS component. This component is a mechanism for the host to identify the format and meaning of the opaque portion of the security attribute. A full mode environment may contain hosts operating in several different LFSs and DOIs. In this case a mechanism for translating the opaque portion of the security attribute is needed. The actual translation function will vary based on MAC model and policy and is out of the scope of this document. If a translation is unavailable for a given LFS and DOI then the request SHOULD be denied. Another recourse is to allow the host to provide a fallback mapping for unknown security attributes. 7.1.2. Policy Enforcement In full mode access control decisions are made by both the clients and servers. When a client makes a request it takes the security attribute from the requesting process and makes an access control decision based on that attribute and the security attribute of the object it is trying to access. If the client denies that access an RPC call to the server is never made. If however the access is allowed the client will make a call to the NFS server. When the server receives the request from the client it extracts the Quiqley, et al. Expires December 24, 2011 [Page 12] Internet-Draft labledNFS June 2011 security attribute conveyed in the RPC request. The server then uses this security attribute and the attribute of the object the client is trying to access to make an access control decision. If the server's policy allows this access it will fulfill the client's request, otherwise it will return NFS4ERR_ACCESS. Implementations MAY validate security attributes supplied over the network to ensure that they are within a set of attributes permitted from a specific peer, and if not, reject them. Note that a system may permit a different set of attributes to be accepted from each peer. An example of this can be seen in Section 8.7.1. 7.2. Smart Client Mode Smart client environments consist of NFSv4 servers that are not MAC aware but NFSv4 clients that are. Clients in this environment are may consist of groups implementing different MAC models policies. The system requires that all clients in the environment be responsible for access control checks. Due to the amount of trust placed in the clients this mode is only to be used in a trusted environment. 7.2.1. Initial Labeling and Translation Just like in full mode the client is responsible for determining the initial label upon object creation. The server in smart client mode does not implement a MAC model, however, it may provide the ability to restrict the creation and labeling of object with certain labels based on different criteria as described in Section 7.1.2. In a smart client environment a group of clients operate in a single DOI. This removes the need for the clients to maintain a set of DOI translations. Servers should provide a method to allow different groups of clients to access the server at the same time. However it should not let two groups of clients operating in different DOIs to access the same files. 7.2.2. Policy Enforcement In smart client mode access control decisions are made by the clients. When a client accesses an object it obtains the security attribute of the object from the server and combines it with the security attribute of the process making the request to make an access control decision. This check is in addition to the DAC checks provided by NFSv4 so this may fail based on the DAC criteria even if the MAC policy grants access. As the policy check is located on the client an access control denial should take the form that is native to the platform. Quiqley, et al. Expires December 24, 2011 [Page 13] Internet-Draft labledNFS June 2011 7.3. Smart Server Mode Smart server environments consist of NFSv4 servers that are MAC aware and one or more MAC unaware clients. The server is the only entity enforcing policy, and may selectively provide standard NFS services to clients based on their authentication credentials and/or associated network attributes (e.g., IP address, network interface). The level of trust and access extended to a client in this mode is configuration-specific. 7.3.1. Initial Labeling and Translation In smart server mode all labeling and access control decisions are performed by the NFSv4 server. In this environment the NFSv4 clients are not MAC aware so they cannot provide input into the access control decision. This requires the server to determine the initial labeling of objects. Normally the subject to use in this calculation would originate from the client. Instead the NFSv4 server may choose to assign the subject security attribute based on their authentication credentials and/or associated network attributes (e.g., IP address, network interface). In smart server mode security attributes are contained solely within the NFSv4 server. This means that all security attributes used in the system remain within a single LFS and DOI. Since security attributes will not cross DOIs or change format there is no need to provide any translation functionality above that which is needed internally by the MAC model. 7.3.2. Policy Enforcement All access control decisions in smart server mode are made by the server. The server will assign the subject a security attribute based on some criteria (e.g., IP address, network interface). Using the newly calculated security attribute and the security attribute of the object being requested the MAC model makes the access control check and returns NFS4ERR_ACCESS on a denial and NFS4_OK on success. This check is done transparently to the client so if the MAC permission check fails the client may be unaware of the reason for the permission failure. When operating in this mode administrators attempting to debug permission failures should be aware to check the MAC policy running on the server in addition to the DAC settings. 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 Quiqley, et al. Expires December 24, 2011 [Page 14] Internet-Draft labledNFS June 2011 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 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 Quiqley, et al. Expires December 24, 2011 [Page 15] Internet-Draft labledNFS June 2011 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. 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 Quiqley, et al. Expires December 24, 2011 [Page 16] Internet-Draft labledNFS June 2011 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 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 Quiqley, et al. Expires December 24, 2011 [Page 17] Internet-Draft labledNFS June 2011 (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. Full Mode 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 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. Smart Client Mode In smart client mode the example is identical to the first part of a full mode operation. A process on the client labeled Secret wishes to access a Top Secret directory. As in the full mode example this is denied since Secret does not dominate Top Secret. If the process Quiqley, et al. Expires December 24, 2011 [Page 18] Internet-Draft labledNFS June 2011 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. Smart Server Mode In a smart server mode 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 full mode 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 is in Smart Client Mode or server is in Smart Server Mode, 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 smart 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. 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 Quiqley, et al. Expires December 24, 2011 [Page 19] Internet-Draft labledNFS June 2011 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, 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] Quiqley, et al. Expires December 24, 2011 [Page 20] Internet-Draft labledNFS June 2011 [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 December 24, 2011 [Page 21]