idnits 2.17.1 draft-quigley-nfsv4-labeled-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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 document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 26, 2011) is 4566 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 5661 (ref. '6') (Obsoleted by RFC 8881) ** Obsolete normative reference: RFC 5226 (ref. '7') (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFSv4 D. Quiqley 3 Internet-Draft Consultant 4 Intended status: Standards Track J. Morris 5 Expires: April 28, 2012 Red Hat 6 J. Lu 7 Oracle 8 T. Haynes, Ed. 9 NetApp 10 S. Smalley 11 NSA 12 October 26, 2011 14 Labeled NFS 15 draft-quigley-nfsv4-labeled-04.txt 17 Abstract 19 This Internet-Draft describes additions to NFSv4 to support Mandatory 20 Access Control systems. The current draft describes the mechanism 21 for transporting a MAC security label using the NFSv4 protocol and 22 the semantics required for that label. In addition to this it 23 describes an example system of using this label in a fully MAC aware 24 environment. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [1]. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt. 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 This Internet-Draft will expire on April 28, 2012. 55 Copyright Notice 57 Copyright (c) 2011 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the BSD License. 70 This document may contain material from IETF Documents or IETF 71 Contributions published or made publicly available before November 72 10, 2008. The person(s) controlling the copyright in some of this 73 material may not have granted the IETF Trust the right to allow 74 modifications of such material outside the IETF Standards Process. 75 Without obtaining an adequate license from the person(s) controlling 76 the copyright in such materials, this document may not be modified 77 outside the IETF Standards Process, and derivative works of it may 78 not be created outside the IETF Standards Process, except to format 79 it for publication as an RFC or to translate it into languages other 80 than English. 82 Table of Contents 84 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 85 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 86 3. MAC Security Attribute . . . . . . . . . . . . . . . . . . . . 6 87 3.1. Interpreting FATTR4_SEC_LABEL . . . . . . . . . . . . . . 7 88 3.2. Delegations . . . . . . . . . . . . . . . . . . . . . . . 8 89 3.3. Permission Checking . . . . . . . . . . . . . . . . . . . 8 90 3.4. Object Creation . . . . . . . . . . . . . . . . . . . . . 8 91 3.5. Existing Objects . . . . . . . . . . . . . . . . . . . . . 8 92 3.6. Label Changes . . . . . . . . . . . . . . . . . . . . . . 9 93 4. Procedure 16: CB_ATTR_CHANGED - Notify Client that the 94 File's Attributes Changed . . . . . . . . . . . . . . . . . . 10 95 5. pNFS Considerations . . . . . . . . . . . . . . . . . . . . . 10 96 6. Discovery of Server LNFS Support . . . . . . . . . . . . . . . 11 97 7. LNFS Areas of Functionality . . . . . . . . . . . . . . . . . 11 98 7.1. Client Object Labeling . . . . . . . . . . . . . . . . . . 11 99 7.2. Client Subject Labeling . . . . . . . . . . . . . . . . . 12 100 7.3. Client Policy Enforcement . . . . . . . . . . . . . . . . 12 101 7.4. Server Object Labeling . . . . . . . . . . . . . . . . . . 12 102 7.5. Server Subject Labeling . . . . . . . . . . . . . . . . . 12 103 7.6. Server Policy Enforcement . . . . . . . . . . . . . . . . 12 104 8. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 13 105 8.1. Full MAC labeling support for remotely mounted 106 filesystems . . . . . . . . . . . . . . . . . . . . . . . 13 107 8.2. MAC labeling of virtual machine images stored on the 108 network . . . . . . . . . . . . . . . . . . . . . . . . . 13 109 8.3. International Traffic in Arms Regulations (ITAR) . . . . . 13 110 8.4. Legal Hold/eDiscovery . . . . . . . . . . . . . . . . . . 14 111 8.5. Simple security label storage . . . . . . . . . . . . . . 15 112 8.6. Diskless Linux . . . . . . . . . . . . . . . . . . . . . . 15 113 8.7. Multi-Level Security . . . . . . . . . . . . . . . . . . . 15 114 8.7.1. Policy-Enforcing Client and Server . . . . . . . . . . 16 115 8.7.2. Policy-Enforcing Client . . . . . . . . . . . . . . . 17 116 8.7.3. Policy-Enforcing Server . . . . . . . . . . . . . . . 17 117 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 118 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 119 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 120 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 121 11.2. Informative References . . . . . . . . . . . . . . . . . . 18 122 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18 123 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 19 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 126 1. Introduction 128 Mandatory Access Control (MAC) systems have been mainstreamed in 129 modern operating systems such as Linux (R), FreeBSD (R), Solaris 130 (TM), and Windows Vista (R). MAC systems bind security attributes to 131 subjects (processes) and objects within a system. These attributes 132 are used with other information in the system to make access control 133 decisions. 135 Access control models such as Unix permissions or Access Control 136 Lists are commonly referred to as Discretionary Access Control (DAC) 137 models. These systems base their access decisions on user identity 138 and resource ownership. In contrast MAC models base their access 139 control decisions on the label on the subject (usually a process) and 140 the object it wishes to access. These labels may contain user 141 identity information but usually contain additional information. In 142 DAC systems users are free to specify the access rules for resources 143 that they own. MAC models base their security decisions on a system 144 wide policy established by an administrator or organization which the 145 users do not have the ability to override. DAC systems offer no real 146 protection against malicious or flawed software due to each program 147 running with the full permissions of the user executing it. 148 Inversely MAC models can confine malicious or flawed software and 149 usually act at a finer granularity than their DAC counterparts. 151 People desire to use NFSv4 with these systems. A mechanism is 152 required to provide security attribute information to NFSv4 clients 153 and servers. This mechanism has the following requirements: 155 (1) Clients must be able to convey to the server the security 156 attribute of the subject making the access request. The server 157 may provide a mechanism to enforce MAC policy based on the 158 requesting subject's security attribute. 160 (2) Server must be able to store and retrieve the security attribute 161 of exported files as requested by the client. 163 (3) Server must provide a mechanism for notifying clients of 164 attribute changes of files on the server. 166 (4) Clients and Servers must be able to negotiate Label Formats and 167 provide a mechanism to translate between them as needed. 169 These four requirements are key to the system with only requirements 170 (2) and (3) requiring changes to NFSv4. The ability to convey the 171 security attribute of the subject as described in requirement (1) 172 falls upon the RPC layer to implement (see [2]). Requirement (4) 173 allows communication between different MAC implementations. The 174 management of label formats and the translation between them does not 175 require any support from NFSv4 on a protocol level and is out of the 176 scope of this document. 178 The first change necessary is to devise a method for transporting and 179 storing security label data on NFSv4 file objects. Security labels 180 have several semantics that are met by NFSv4 recommended attributes 181 such as the ability to set the label value upon object creation. 182 Access control on these attributes are done through a combination of 183 two mechanisms. As with other recommended attributes on file objects 184 the usual DAC checks (ACLs and permission bits) will be performed to 185 ensure that proper file ownership is enforced. In addition a MAC 186 system MAY be employed on the client, server, or both to enforce 187 additional policy on what subjects may modify security label 188 information. 190 The second change is to provide a method for the server to notify the 191 client that the attribute changed on an open file on the server. If 192 the file is closed, then during the open attempt, the client will 193 gather the new attribute value. The server MUST not communicate the 194 new value of the attribute, the client MUST query it. This 195 requirement stems from the need for the client to provide sufficient 196 access rights to the attribute. 198 The final change necessary is a modification to the RPC layer used in 199 NFSv4 in the form of a new version of the RPCSEC_GSS [3] framework. 200 In order for an NFSv4 server to apply MAC checks it must obtain 201 additional information from the client. Several methods were 202 explored for performing this and it was decided that the best 203 approach was to incorporate the ability to make security attribute 204 assertions through the RPC mechanism. RPCSECGSSv3 [2] outlines a 205 method to assert additional security information such as security 206 labels on gss context creation and have that data bound to all RPC 207 requests that make use of that context. 209 2. Definitions 211 Label Format Specifier (LFS): is an identifier used by the client to 212 establish the syntactic format of the security label and the 213 semantic meaning of its components. These specifiers exist in a 214 registry associated with documents describing the format and 215 semantics of the label. 217 Label Format Registry: is the IANA registry containing all 218 registered LFS along with references to the documents that 219 describe the syntactic format and semantics of the security label. 221 Policy Identifier (PI): is an optional part of the definition of a 222 Label Format Specifier which allows for clients and server to 223 identify specific security policies. 225 Object: is a passive resource within the system that we wish to be 226 protected. Objects can be entities such as files, directories, 227 pipes, sockets, and many other system resources relevant to the 228 protection of the system state. 230 Subject: A subject is an active entity usually a process which is 231 requesting access to an object. 233 Multi-Level Security (MLS): is a traditional model where objects are 234 given a sensitivity level (Unclassified, Secret, Top Secret, etc) 235 and a category set [8]. 237 3. MAC Security Attribute 239 MAC models base access decisions on security attributes bound to 240 subjects and objects. This information can range from a user 241 identity for an identity based MAC model, sensitivity levels for 242 Multi-level security, or a type for Type Enforcement. These models 243 base their decisions on different criteria but the semantics of the 244 security attribute remain the same. The semantics required by the 245 security attributes are listed below: 247 o Must provide flexibility with respect to MAC model. 249 o Must provide the ability to atomically set security information 250 upon object creation 252 o Must provide the ability to enforce access control decisions both 253 on the client and the server 255 o Must not expose an object to either the client or server name 256 space before its security information has been bound to it. 258 NFSv4 provides several options for implementing the security 259 attribute. The first option is to implement the security attribute 260 as a named attribute. Named attributes provide flexibility since 261 they are treated as an opaque field but lack a way to atomically set 262 the attribute on creation. In addition, named attributes themselves 263 are file system objects which need to be assigned a security 264 attribute. This raises the question of how to assign security 265 attributes to the file and directories used to hold the security 266 attribute for the file in question. The inability to atomically 267 assign the security attribute on file creation and the necessity to 268 assign security attributes to its sub-components makes named 269 attributes unacceptable as a method for storing security attributes. 271 The second option is to implement the security attribute as a 272 recommended attribute. These attributes have a fixed format and 273 semantics, which conflicts with the flexible nature of the security 274 attribute. To resolve this the security attribute consists of two 275 components. The first component is a LFS as defined in [4] to allow 276 for interoperability between MAC mechanisms. The second component is 277 an opaque field which is the actual security attribute data. To 278 allow for various MAC models NFSv4 should be used solely as a 279 transport mechanism for the security attribute. It is the 280 responsibility of the endpoints to consume the security attribute and 281 make access decisions based on their respective models. In addition, 282 creation of objects through OPEN and CREATE allows for the security 283 attribute to be specified upon creation. By providing an atomic 284 create and set operation for the security attribute it is possible to 285 enforce the second and fourth requirements. The recommended 286 attribute FATTR4_SEC_LABEL will be used to satisfy this requirement. 288 3.1. Interpreting FATTR4_SEC_LABEL 290 The XDR [5] necessary to implement Labeled NFSv4 is presented in 291 Figure 1: 293 const FATTR4_SEC_LABEL = 81; 295 typedef uint32_t policy4; 296 struct labelformat_spec4 { 297 policy4 lfs_lfs; 298 policy4 lfs_pi; 299 }; 301 struct sec_label_attr_info { 302 labelformat_spec4 slai_lfs; 303 opaque slai_data<>; 304 }; 306 Figure 1 308 The FATTR4_SEC_LABEL contains an array of two components with the 309 first component being an LFS. It serves to provide the receiving end 310 with the information necessary to translate the security attribute 311 into a form that is usable by the endpoint. Label Formats assigned 312 an LFS may optionally choose to include a Policy Identifier field to 313 allow for complex policy deployments. The LFS and Label Format 314 Registry are described in detail in [4]. The translation used to 315 interpret the security attribute is not specified as part of the 316 protocol as it may depend on various factors. The second component 317 is an opaque section which contains the data of the attribute. This 318 component is dependent on the MAC model to interpret and enforce. 320 In particular, it is the responsibility of the LFS specification to 321 define a maximum size for the opaque section, slai_data<>. When 322 creating or modifying a label for an object, the client needs to be 323 guaranteed that the server will accept a label that is sized 324 correctly. By both client and server being part of a specific MAC 325 model, the client will be aware of the size. 327 3.2. Delegations 329 In the event that a security attribute is changed on the server while 330 a client holds a delegation on the file, the client should follow the 331 existing protocol with respect to attribute changes. It should flush 332 all changes back to the server and relinquish the delegation. 334 3.3. Permission Checking 336 It is not feasible to enumerate all possible MAC models and even 337 levels of protection within a subset of these models. This means 338 that the NFSv4 client and servers cannot be expected to directly make 339 access control decisions based on the security attribute. Instead 340 NFSv4 should defer permission checking on this attribute to the host 341 system. These checks are performed in addition to existing DAC and 342 ACL checks outlined in the NFSv4 protocol. Section 8 gives a 343 specific example of how the security attribute is handled under a 344 particular MAC model. 346 3.4. Object Creation 348 When creating files in NFSv4 the OPEN and CREATE operations are used. 349 One of the parameters to these operations is an fattr4 structure 350 containing the attributes the file is to be created with. This 351 allows NFSv4 to atomically set the security attribute of files upon 352 creation. When a client is MAC aware it must always provide the 353 initial security attribute upon file creation. In the event that the 354 server is the only MAC aware entity in the system it should ignore 355 the security attribute specified by the client and instead make the 356 determination itself. 358 3.5. Existing Objects 360 Note that under the MAC model, all objects must have labels. 361 Therefore, if an existing server is upgraded to include LNFS support, 362 then it is the responsibility of the security system to define the 363 behavior for existing objects. For example, if the security system 364 is LFS 0, which means the server just stores and returns labels, then 365 existing files should return labels which are set to an empty value. 367 3.6. Label Changes 369 As per the requirements, when a file's security label is modified, 370 the server must notify all clients which have the file opened of the 371 change in label. It does so with CB_ATTR_CHANGED. There are 372 preconditions to making an attribute change imposed by NFSv4 and the 373 security system might want to impose others. In the process of 374 meeting these preconditions, the server may chose to either serve the 375 request in whole or return NFS4ERR_DELAY to the SETATTR operation. 377 If there are open delegations on the file belonging to client other 378 than the one making the label change, then the process described in 379 Section 3.2 must be followed. 381 As the server is always presented with the subject label from the 382 client, it does not necessarily need to communicate the fact that the 383 label has changed to the client. In the cases where the change 384 outright denies the client access, the client will be able to quickly 385 determine that there is a new label in effect. It is in cases where 386 the client may share the same object between multiple subjects or a 387 security system which is not strictly hierarchical that the 388 CB_ATTR_CHANGED callback is very useful. It allows the server to 389 inform the clients that the cached security attribute is now stale. 391 In the scenario presented in Section 8.5, the clients provide policy 392 enforcement functionality and the server only provides object 393 labeling functionality. In order to ensure that policy is enforced 394 upon a label change in this situation, if client A changes a security 395 label on a file, then the server MUST inform all clients that have 396 the file opened that the label has changed via CB_ATTR_CHANGED. Then 397 the clients MUST retrieve the new label and MUST enforce access via 398 the new attribute values. 400 [[Comment.1: Describe a LFS of 0, which will be the means to indicate 401 such a deployment. In the current LFR, 0 is marked as reserved. If 402 we use it, then we define the default LFS to be used by a LNFS aware 403 server. I.e., it enables policy-enforcing clients to work together 404 in the face of a server that only supports object labeling. Note 405 that while supporting this system is optional, it will make for a 406 very good debugging mode during development. I.e., even if a server 407 does not deploy with another security system, this mode gets your 408 foot in the door. --TH]] 410 4. Procedure 16: CB_ATTR_CHANGED - Notify Client that the File's 411 Attributes Changed 413 4.1. ARGUMENTS 415 struct CB_ATTR_CHANGED4args { 416 nfs_fh4 acca_fh; 417 bitmap4 acca_critical; 418 bitmap4 acca_info; 419 }; 421 4.2. RESULTS 423 struct CB_ATTR_CHANGED4res { 424 nfsstat4 accr_status; 425 }; 427 4.3. DESCRIPTION 429 The CB_ATTR_CHANGED callback operation is used by the server to 430 indicate to the client that the file's attributes have been modified 431 on the server. The server does not convey how the attributes have 432 changed, just that they have been modified. The server can inform 433 the client about both critical and informational attribute changes in 434 the bitmask arguments. The client SHOULD query the server about all 435 attributes set in acca_critical. For all changes reflected in 436 acca_info, the client can decide whether or not it wants to poll the 437 server. 439 The CB_ATTR_CHANGED callback operation with the FATTR4_SEC_LABEL set 440 in acca_critical is the method used by the server to indicate that 441 the MAC label for the file referenced by acca_fh has changed. In 442 many ways, the server does not care about the result returned by the 443 client. 445 5. pNFS Considerations 447 This section examines the issues in deploying LNFS in a pNFS 448 community of servers. 450 5.1. MAC Label Checks 452 The new FATTR4_SEC_LABEL attribute is metadata information and as 453 such the DS is not aware of the value contained on the MDS. 454 Fortunately, the NFSv4.1 protocol [6] already has provisions for 455 doing access level checks from the DS to the MDS. In order for the 456 DS to validate the subject label presented by the client, it SHOULD 457 utilize this mechanism. 459 If a file's FATTR4_SEC_LABEL is changed, then the MDS should utilize 460 CB_ATTR_CHANGED to inform the client of that fact. If the MDS is 461 maintaining 463 6. Discovery of Server LNFS Support 465 The server can easily determine that a client supports LNFS when it 466 queries for the FATTR4_SEC_LABEL label for an object. Note that it 467 cannot assume that the presence of RPCSEC_GSSv3 indicates LNFS 468 support. The client might need to discover which LFS the server 469 supports. 471 A server which supports LNFS MUST allow a client with any subject 472 label to retrieve the FATTR4_SEC_LABEL attribute for the root 473 filehandle, ROOTFH. The following compound must always succeed as 474 far as a MAC label check is concerned: 476 PUTROOTFH, GETATTR {FATTR4_SEC_LABEL} 478 Note that the server might have imposed a security flavor on the root 479 that precludes such access. I.e., if the server requires kerberized 480 access and the client presents a compound with AUTH_SYS, then the 481 server is allowed to return NFS4ERR_WRONGSEC in this case. But if 482 the client presents a correct security flavor, then the server MUST 483 return the FATTR4_SEC_LABEL attribute with the supported LFS filled 484 in. 486 7. LNFS Areas of Functionality 488 LNFS functionality falls into three areas for both clients and 489 servers: object label functionality, subject label functionality, and 490 policy enforcement. The three areas of functionality are independent 491 in the protocol specification, but in practice, clients or servers 492 that support subject label functionality will typically also support 493 object label functionality, and servers that support policy 494 enforcement will typically also support subject and object label 495 functionality. 497 7.1. Client Object Labeling 499 Client object label functionality falls into two areas: 501 Specifying the MAC security attribute for file creation requests 502 as described in Section 3.4. 504 Handling label change callbacks from the server as described in 505 Section 3.6. 507 7.2. Client Subject Labeling 509 Client subject label functionality consists of asserting the subject 510 label for the requesting process on the client to the server. The 511 security attribute of the subject making the request is transported 512 at the RPC layer using the mechanism described in RPCSECGSSv3 [2]. 514 7.3. Client Policy Enforcement 516 Client policy enforcement functionality consists of applying MAC 517 policy checks based on the subject label of the requesting process on 518 the client and the object label of the file. If object labeling is 519 supported by the server, then the client will use the object label 520 provided by the server for the access decision. If not, then the 521 client may infer an object label for the file based on other criteria 522 at its disposal, e.g. based on the server identity, the particular 523 mount, or a local mapping. 525 7.4. Server Object Labeling 527 Server object label functionality falls into two areas: 529 Storing and returning file labels. 531 Sending label change callbacks when a label change is performed. 533 7.5. Server Subject Labeling 535 Server subject label functionality consists of accepting RPCSEC_GSSv3 536 label assertions. 538 7.6. Server Policy Enforcement 540 Server policy enforcement functionality consists of applying MAC 541 policy checks based on the subject label of the requesting process on 542 the client and the object label of the file. If the client and the 543 server both support subject label functionality, then the subject 544 label provided by the client will be used for the access decision. 545 If either the client or the server do not support subject label 546 functionality, then the server may infer a subject label based on 547 other criteria at its disposal, e.g. based on the client identity. 548 If the server supports object label functionality, then the object 549 label that is stored with the file will be used for the access 550 decision. If not, then an object label may be inferred from other 551 criteria at its disposal, e.g. based on the exported filesystem or 552 some local mapping. 554 8. Use Cases 556 MAC labeling is meant to allow NFSv4 to be deployed in site 557 configurable security schemes. The LFS and opaque data scheme allows 558 for flexibility to meet these different implementations. In this 559 section, we provide some examples of how NFSv4 could be deployed to 560 meet existing needs. This is not an exhaustive listing. 562 8.1. Full MAC labeling support for remotely mounted filesystems 564 In this case, we assume a local networked environment where the 565 servers and clients are under common administrative control. All 566 systems in this network have the same MAC implementation and 567 semantically identical MAC security labels for objects (i.e. labels 568 mean the same thing on different systems, even if the policies on 569 each system may differ to some extent). Clients will be able to 570 apply fine-grained MAC policy to objects accessed via NFS mounts, and 571 thus improve the overall consistency of MAC policy application within 572 this environment. 574 An example of this case would be where user home directories are 575 remotely mounted, and fine-grained MAC policy is implemented to 576 protect, for example, private user data from being read by malicious 577 web scripts running in the user's browser. With Labeled NFS, fine- 578 grained MAC labeling of the user's files will allow the local MAC 579 policy to be implemented and provide the desired protection. 581 8.2. MAC labeling of virtual machine images stored on the network 583 Virtualization is now a commonly implemented feature of modern 584 operating systems, and there is a need to ensure that MAC security 585 policy is able to to protect virtualized resources. A common 586 implementation scheme involves storing virtualized guest filesystems 587 on a networked server, which are then mounted remotely by guests upon 588 instantiation. In this case, there is a need to ensure that the 589 local guest kernel is able to access fine-grained MAC labels on the 590 remotely mounted filesystem so that its MAC security policy can be 591 applied. 593 8.3. International Traffic in Arms Regulations (ITAR) 595 The International Traffic in Arms Regulations (ITAR) is put forth by 596 the United States Department of State, Directorate of Defense and 597 Trade Controls. ITAR places strict requirements on the export and 598 thus access of defense articles and defense services. Organizations 599 that manage projects with articles and services deemed as within the 600 scope of ITAR must ensure the regulations are met. The regulations 601 require an assurance that ITAR information is accessed on a need-to- 602 know basis, thus requiring strict, centrally managed access controls 603 on items labeled as ITAR. Additionally, organizations must be able 604 to prove that the controls were adequately maintained and that 605 foreign nationals were not permitted access to these defense articles 606 or service. ITAR control applicability may be dynamic; information 607 may become subject to ITAR after creation (e.g., when the defense 608 implications of technology are recognized). 610 8.4. Legal Hold/eDiscovery 612 Increased cases of legal holds on electronic sources of information 613 (ESI) have resulted in organizations taking a pro-active approach to 614 reduce the scope and thus costs associated with these activities. 615 ESI Data Maps are increasing in use and require support in operating 616 systems to strictly manage access controls in the case of a legal 617 hold. The sizeable quantity of information involved in a legal 618 discovery request may preclude making a copy of the information to a 619 separate system that manages the legal hold on the copies; this 620 results in a need to enforce the legal hold on the original 621 information. 623 Organizations are taking steps to map out the sources of information 624 that are most likely to be placed under a legal hold, these efforts 625 result in ESI Data Maps. ESI Data Maps specify the Electronic Source 626 of Information and the requirements for sensitivity and criticality. 627 In the case of a legal hold, the ESI data map and labels can be used 628 to ensure the legal hold is properly enforced on the predetermined 629 set of information. An ESI data map narrows the scope of a legal 630 hold to the predetermined ESI. The information must then be 631 protected at a level of security of which the weight and 632 admissibility of that evidence may be proved in a court of law. 633 Current systems use application level controls and do not adequately 634 meet the requirements. Labels may be used in advance when an ESI 635 data map exercise is conducted with controls being applied at the 636 time of a hold or labels may be applied to data sets during an 637 eDiscovery exercise to ensure the data protections are adequate 638 during the legal hold period. 640 Note that this use case requires multi-attribute labels, as both 641 information sensitivity (e.g., to disclosure) and information 642 criticality (e.g., to continued business operations) need to be 643 captured. 645 8.5. Simple security label storage 647 In this case, a mixed and loosely administered network is assumed, 648 where nodes may be running a variety of operating systems with 649 different security mechanisms and security policies. It is desired 650 that network file servers be simply capable of storing and retrieving 651 MAC security labels for clients which use such labels. The Labeled 652 NFS protocol would be implemented here solely to enable transport of 653 MAC security labels across the network. It should be noted that in 654 such an environment, overall security cannot be as strongly enforced 655 as in case (a), and that this scheme is aimed at allowing MAC-capable 656 clients to function with local MAC security policy enabled rather 657 than perhaps disabling it entirely. 659 8.6. Diskless Linux 661 A number of popular operating system distributions depend on a 662 mandatory access control (MAC) model to implement a kernel-enforced 663 security policy. Typically, such models assign particular roles to 664 individual processes, which limit or permit performing certain 665 operations on a set of files, directories, sockets, or other objects. 666 While the enforcing of the policy is typically a matter for the 667 diskless NFS client itself, the filesystem objects in such models 668 will typically carry MAC labels that are used to define policy on 669 access. These policies may, for instance, describe privilege 670 transitions that cannot be replicated using standard NFS ACL based 671 models. 673 For instance on a SYSV compatible system, if the 'init' process 674 spawns a process that attempts to start the 'NetworkManager' 675 executable, there may be a policy that sets up a role transition if 676 the 'init' process and 'NetworkManager' file labels match a 677 particular rule. Without this role transition, the process may find 678 itself having insufficient privileges to perform its primary job of 679 configuring network interfaces. 681 In setups of this type, a lot of the policy targets (such as sockets 682 or privileged system calls) are entirely local to the client. The 683 use of RPCSEC_GSSv3 for enforcing compliance at the server level is 684 therefore of limited value. The ability to permanently label files 685 and have those labels read back by the client is, however, crucial to 686 the ability to enforce that policy. 688 8.7. Multi-Level Security 690 In a MLS system objects are generally assigned a sensitivity level 691 and a set of compartments. The sensitivity levels within the system 692 are given an order ranging from lowest to highest classification 693 level. Read access to an object is allowed when the sensitivity 694 level of the subject "dominates" the object it wants to access. This 695 means that the sensitivity level of the subject is higher than that 696 of the object it wishes to access and that its set of compartments is 697 a super-set of the compartments on the object. 699 The rest of the section will just use sensitivity levels. In general 700 the example is a client that wishes to list the contents of a 701 directory. The system defines the sensitivity levels as Unclassified 702 (U), Secret (S), and Top Secret (TS). The directory to be searched 703 is labeled Top Secret which means access to read the directory will 704 only be granted if the subject making the request is also labeled Top 705 Secret. 707 8.7.1. Policy-Enforcing Client and Server 709 In the first part of this example a process on the client is running 710 at the Secret level. The process issues a readdir system call which 711 enters the kernel. Before translating the readdir system call into a 712 request to the NFSv4 server the host operating system will consult 713 the MAC module to see if the operation is allowed. Since the process 714 is operating at Secret and the directory to be accessed is labeled 715 Top Secret the MAC module will deny the request and an error code is 716 returned to user space. 718 Consider a second case where instead of running at Secret the process 719 is running at Top Secret. In this case the sensitivity of the 720 process is equal to or greater than that of the directory so the MAC 721 module will allow the request. Now the readdir is translated into 722 the necessary NFSv4 call to the server. For the RPC request the 723 client is using the proper credential to assert to the server that 724 the process is running at Top Secret. 726 When the server receives the request it extracts the security label 727 from the RPC session and retrieves the label on the directory. The 728 server then checks with its MAC module if a Top Secret process is 729 allowed to read the contents of the Top Secret directory. Since this 730 is allowed by the policy then the server will return the appropriate 731 information back to the client. 733 In this example the policy on the client and server were both the 734 same. In the event that they were running different policies a 735 translation of the labels might be needed. In this case it could be 736 possible for a check to pass on the client and fail on the server. 737 The server may consider additional information when making its policy 738 decisions. For example the server could determine that a certain 739 subnet is only cleared for data up to Secret classification. If that 740 constraint was in place for the example above the client would still 741 succeed, but the server would fail since the client is asserting a 742 label that it is not able to use (Top Secret on a Secret network). 744 8.7.2. Policy-Enforcing Client 746 With a policy-enforcing client and a label-unaware server, this 747 example is identical to the first part of the previous example. A 748 process on the client labeled Secret wishes to access a Top Secret 749 directory. As in the previous example, this is denied since Secret 750 does not dominate Top Secret. If the process were operating at Top 751 Secret it would pass the local access control check and the NFSv4 752 operation would proceed as in a normal NFSv4 environment. 754 8.7.3. Policy-Enforcing Server 756 With a policy-enforcing server and a label-unaware client, the client 757 behaves as if it were in a normal NFSv4 environment. Since the 758 process on the client does not provide a security attribute the 759 server must define a mechanism for labeling all requests from a 760 client. Assume that the server is using the same criteria used in 761 the first example. The server sees the request as coming from a 762 subnet that is a Secret network. The server determines that all 763 clients on that subnet will have their requests labeled with Secret. 764 Since the directory on the server is labeled Top Secret and Secret 765 does not dominate Top Secret the server would fail the request with 766 NFS4ERR_ACCESS. 768 9. Security Considerations 770 This entire document deals with security issues. 772 Depending on the level of protection the MAC system offers there may 773 be a requirement to tightly bind the security attribute to the data. 775 When either the client or the server is label-unaware, it is 776 important to realize that the other side is not enforcing MAC 777 protections. Alternate methods might be in use to handle the lack of 778 MAC support and care should be taken to identify and mitigate threats 779 from possible tampering outside of these methods. 781 An example of this is that a policy-enforcing server that modifies 782 READDIR or LOOKUP results based on the client's subject label might 783 want to always construct the same subject label for a client which 784 does not present one. This will prevent a non-LNFS client from 785 mixing entries in the directory cache. 787 10. IANA Considerations 789 This section uses terms that are defined in [7]. 791 The LFS and Label Format Registry are described in detail in [4]. 793 11. References 795 11.1. Normative References 797 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 798 Levels", March 1997. 800 [2] Haynes, T. and N. Williams, "Remote Procedure Call (RPC) 801 Security Version 3", draft-williams-rpcsecgssv3 (work in 802 progress), 2011. 804 [3] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 805 Specification", RFC 2203, September 1997. 807 [4] Quigley, D. and J. Lu, "Registry Specification for MAC Security 808 Label Formats", draft-quigley-label-format-registry (work in 809 progress), 2011. 811 [5] Eisler, M., "XDR: External Data Representation Standard", 812 RFC 4506, May 2006. 814 [6] Shepler, S., Eisler, M., and D. Noveck, "Network File System 815 (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, 816 January 2010. 818 [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 819 Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 821 11.2. Informative References 823 [8] "Section 46.6. Multi-Level Security (MLS) of Deployment Guide: 824 Deployment, configuration and administration of Red Hat 825 Enterprise Linux 5, Edition 6", 2011. 827 Appendix A. Acknowledgments 829 Kathleen Moriarty provided the use cases for ITAR and Legal Hold/ 830 eDiscovery. 832 Dan Walsh provided use cases for Secure Virtualization, Sandboxing, 833 and NFS homedir labeling to handle process separation. 835 Trond Myklebust provided use cases for secure diskless NFS clients. 837 Appendix B. RFC Editor Notes 839 [RFC Editor: please remove this section prior to publishing this 840 document as an RFC] 842 [RFC Editor: prior to publishing this document as an RFC, please 843 replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the 844 RFC number of this document] 846 Authors' Addresses 848 David Quigley 849 Consultant 851 Email: dpquigl@davequigley.com 853 James Morris 854 Red Hat, Inc. 856 Email: jmorris@namei.org 858 Jarrett Lu 859 Oracle 861 Email: jarrett.lu@oracle.com 863 Thomas Haynes (editor) 864 NetApp 865 9110 E 66th St 866 Tulsa, OK 74133 867 USA 869 Phone: +1 918 307 1415 870 Email: thomas@netapp.com 871 Stephen Smalley 872 National Security Agency 874 Email: sds@tycho.nsa.gov