idnits 2.17.1 draft-ietf-nfsv4-labreqs-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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: Labeled NFS modifications to standard NFSv4.2 [3] implementations MUST not adversely impact any existing interoperability of those implementations. == 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 'SHOULD not' in this paragraph: The server MUST honor the ability for a client to specify the label of an object on creation. If the server is MAC enabled it may choose to reject the label specified by the client due to restrictions in the server policy. The server SHOULD not attempt to find a suitable label for an object in event of different labeling rules on its end. The server is allowed to translate the label but SHOULD not change the semantic meaning of the label. == 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 'SHOULD not' in this paragraph: The MAC-Functional client determines if a process request is sent to the remote server. Upon a successful response from the server, it must use its own policies on the object's security labels to determine if the process can be given access. The client SHOULD not need to be cognizant if the server is either a Limited Server or fully MAC-Functional. == 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: As the requirement is a policy, it can be met with the use of a MAC model. Let L be a LFS which implements the Limited Server mode, i.e., a MAC-Aware server connected to MAC-Functional clients. Then a new LFS L' can be created which has the additional policy that the MAC-Aware server MUST not accept any requests from a non-MAC-Functional client. == 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 (May 18, 2012) is 4362 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' == Outdated reference: A later version (-41) exists of draft-ietf-nfsv4-minorversion2-08 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFSv4 T. Haynes, Ed. 3 Internet-Draft NetApp 4 Intended status: Standards Track May 18, 2012 5 Expires: November 19, 2012 7 Requirements for Labeled NFS 8 draft-ietf-nfsv4-labreqs-03.txt 10 Abstract 12 This Internet-Draft outlines high-level requirements for the 13 integration of flexible Mandatory Access Control (MAC) functionality 14 into NFSv4.2. It describes the level of protections that should be 15 provided over protocol components and the basic structure of the 16 proposed system. It also gives a brief explanation of what kinds of 17 protections MAC systems offer. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [1]. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 19, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3.1. Portability & Interoperability . . . . . . . . . . . . . . 5 75 3.2. Performance & Scalability . . . . . . . . . . . . . . . . 6 76 3.3. Security Services . . . . . . . . . . . . . . . . . . . . 6 77 3.4. Label Encoding, Label Format Specifiers, and Label 78 Checking Authorities . . . . . . . . . . . . . . . . . . . 7 79 3.5. Modes of Operation . . . . . . . . . . . . . . . . . . . . 8 80 3.5.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 8 81 3.5.2. Limited Server Mode . . . . . . . . . . . . . . . . . 9 82 3.5.3. Guest Mode . . . . . . . . . . . . . . . . . . . . . . 9 83 3.6. Labeling . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 3.6.1. Client Labeling . . . . . . . . . . . . . . . . . . . 10 85 3.6.2. Server Labeling . . . . . . . . . . . . . . . . . . . 10 86 3.7. Policy Enforcement . . . . . . . . . . . . . . . . . . . . 10 87 3.7.1. Client Enforcement . . . . . . . . . . . . . . . . . . 11 88 3.7.2. Server Enforcement . . . . . . . . . . . . . . . . . . 11 89 3.8. Namespace Access . . . . . . . . . . . . . . . . . . . . . 11 90 3.9. Upgrading Existing Server . . . . . . . . . . . . . . . . 12 91 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 12 92 4.1. Full MAC labeling support for remotely mounted 93 filesystems . . . . . . . . . . . . . . . . . . . . . . . 12 94 4.2. MAC labeling of virtual machine images stored on the 95 network . . . . . . . . . . . . . . . . . . . . . . . . . 12 96 4.3. International Traffic in Arms Regulations (ITAR) . . . . . 13 97 4.4. Legal Hold/eDiscovery . . . . . . . . . . . . . . . . . . 13 98 4.5. Simple security label storage . . . . . . . . . . . . . . 14 99 4.6. Diskless Linux . . . . . . . . . . . . . . . . . . . . . . 14 100 4.7. Multi-Level Security . . . . . . . . . . . . . . . . . . . 15 101 4.7.1. Full Mode - MAC-functional Client and Server . . . . . 15 102 4.7.2. MAC-Functional Client . . . . . . . . . . . . . . . . 16 103 4.7.3. MAC-Functional Server . . . . . . . . . . . . . . . . 16 104 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 105 5.1. Trust Needed for a Community . . . . . . . . . . . . . . . 17 106 5.2. Guest Modes . . . . . . . . . . . . . . . . . . . . . . . 17 107 5.3. MAC-Functional Client Configuration . . . . . . . . . . . 17 108 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 109 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 110 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 111 7.2. Informative References . . . . . . . . . . . . . . . . . . 18 112 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 19 113 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 19 114 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 116 1. Introduction 118 Mandatory Access Control (MAC) systems have been mainstreamed in 119 modern operating systems such as Linux (R), FreeBSD (R), and Solaris 120 (TM). MAC systems bind security attributes to subjects (processes) 121 and objects within a system. These attributes are used with other 122 information in the system to make access control decisions. 124 Access control models such as Unix permissions or Access Control 125 Lists are commonly referred to as Discretionary Access Control (DAC) 126 models. These systems base their access decisions on user identity 127 and resource ownership. In contrast MAC models base their access 128 control decisions on the label on the subject (usually a process) and 129 the object it wishes to access. These labels may contain user 130 identity information but usually contain additional information. In 131 DAC systems users are free to specify the access rules for resources 132 that they own. MAC models base their security decisions on a system 133 wide policy established by an administrator or organization which the 134 users do not have the ability to override. DAC systems offer no real 135 protection against malicious or flawed software due to each program 136 running with the full permissions of the user executing it. 137 Inversely MAC models can confine malicious or flawed software and 138 usually act at a finer granularity than their DAC counterparts. 140 People desire to use NFSv4 with these systems. A mechanism is 141 required to provide security attribute information to NFSv4 clients 142 and servers. This mechanism has the following requirements: 144 (1) Clients MUST be able to convey to the server the security 145 attribute of the subject making the access request. The server 146 may provide a mechanism to enforce MAC policy based on the 147 requesting subject's security attribute. 149 (2) Servers MUST be able to store and retrieve the security 150 attribute of exported files as requested by the client. 152 (3) Servers MUST provide a mechanism for notifying clients of 153 attribute changes of files on the server. 155 (4) Clients and Servers MUST be able to negotiate Label Formats and 156 provide a mechanism to translate between them as needed. 158 2. Definitions 159 Label Format Specifier (LFS): is an identifier used by the client to 160 establish the syntactic format of the security label and the 161 semantic meaning of its components. 163 Label Format Registry: is the IANA registry (see [2]) containing all 164 registered LFS along with references to the documents that 165 describe the syntactic format and semantics of the security label. 167 Policy Identifier (PI): is an optional part of the definition of a 168 Label Format Specifier which allows for clients and server to 169 identify specific security policies. 171 Object: is a passive resource within the system that we wish to be 172 protected. Objects can be entities such as files, directories, 173 pipes, sockets, and many other system resources relevant to the 174 protection of the system state. 176 Subject: is an active entity, usually a process, which is requesting 177 access to an object. 179 MAC-Aware: is a server which can transmit and store object labels. 181 MAC-Functional: is a client or server which is Labeled NFS enabled. 182 Such a system can interpret labels and apply policies based on the 183 security system. 185 Multi-Level Security (MLS): is a traditional model where objects are 186 given a sensitivity level (Unclassified, Secret, Top Secret, etc) 187 and a category set [5]. 189 3. Requirements 191 The following initial requirements have been gathered from users, 192 developers, and from previous development efforts in this area such 193 as DTOS [6] and NSA's experimental NFSv3 enhancements [7]. 195 3.1. Portability & Interoperability 197 Labeled NFS MUST be designed with portability in mind, to facilitate 198 implementations on any operating system that supports mandatory 199 access controls. 201 Labeled NFS MUST be designed and developed to facilitate 202 interoperability between different Labeled NFS implementations. 204 Labeled NFS modifications to standard NFSv4.2 [3] implementations 205 MUST not adversely impact any existing interoperability of those 206 implementations. 208 3.2. Performance & Scalability 210 Security mechanisms often impact on system performance. Labeled NFS 211 SHOULD be designed and implemented in a way which avoids significant 212 performance impact where possible. 214 As NFSv4.2 is designed for large-scale distributed networking, 215 Labeled NFS SHOULD also be capable of scaling in a similar manner to 216 underlying implementations where possible. 218 Labeled NFS SHOULD respond in a robust manner to system and network 219 outages associated with typical enterprise and Internet environments. 220 At the very least, Labeled NFS SHOULD always operate in a fail-safe 221 manner, so that service disruptions do not cause or facilitate 222 security vulnerabilities. 224 3.3. Security Services 226 Labeled NFS SHOULD ensure that the following security services are 227 provided for all NFSv4.2 messaging. These services may be provided 228 by lower layers even if NFS has to be aware of and leverage them: 230 o Authentication 232 o Integrity 234 o Privacy 236 Mechanisms and algorithms used in the provision of security services 237 MUST be configurable, so that appropriate levels of protection may be 238 flexibly specified per mandatory security policy. 240 Strong mutual authentication will be required between the server and 241 the client for Full Mode operation Section 3.5.1. 243 MAC security labels and any related security state SHOULD always be 244 protected by these security services when transferred over the 245 network; as SHOULD the binding of labels and state to associated 246 objects and subjects. 248 Labeled NFS SHOULD support authentication on a context granularity so 249 that different contexts running on a client can use different 250 cryptographic keys and facilities. 252 3.4. Label Encoding, Label Format Specifiers, and Label Checking 253 Authorities 255 Encoding of MAC labels and attributes passed over the network MUST be 256 specified in a complete and unambiguous manner while maintaining the 257 flexibility of MAC implementations. To accomplish this the labels 258 MUST consist of an opaque component bound with a Label Format 259 Specifier (LFS). The LFS component provides a mechanism for 260 identifying the structure and semantics of the opaque component. 261 Meanwhile, the opaque component is the security label which will be 262 interpreted by the MAC models. 264 MAC models base access decisions on security attributes bound to 265 subjects and objects. With a given MAC model, all systems have 266 semantically coherent labeling - a security label MUST always mean 267 exactly the same thing on every system. While this may not be 268 necessary for simple MAC models it is recommended that most label 269 formats assigned an LFS incorporate this concept into their label 270 format. 272 Labeled NFS MUST provide a means for servers and clients to identify 273 their LFS for the purposes of authorization, security service 274 selection, and security label interpretation. 276 A negotiation scheme SHOULD be provided, allowing systems from 277 different label formats to agree on how they will interpret or 278 translate each others labels. Multiple concurrent agreements may be 279 current between a server and a client. 281 All security labels and related security state transferred across the 282 network MUST be tagged with a valid LFS. 284 If the LFS supported on a system changes, it SHOULD renegotiate 285 agreements to reflect these changes. 287 If a system receives any security label or security state tagged with 288 an LFS it does not recognize or cannot interpret, it MUST reject that 289 label or state. 291 NFSv4.2 includes features which may cause a client to cross an LFS 292 boundary when accessing what appears to be a single file system. If 293 LFS negotiation is supported by the client and the server, the server 294 SHOULD negotiate a new, concurrent agreement with the client, acting 295 on behalf of the externally located source of the files. 297 Labeled NFS SHOULD define an initial negotiation scheme with the 298 primary aims of simplicity and completeness. This is to facilitate 299 practical deployment of systems without being weighed down by complex 300 and over-generalized global schemes. Future extensibility SHOULD 301 also be taken into consideration. 303 3.5. Modes of Operation 305 In a Labeled NFS client and server interaction, we can describe three 306 modes of operation: 308 1. Full 310 2. Limited Server 312 3. Guest 314 These modes arise from the level of MAC functionality in the clients 315 and servers. The clients can be non-MAC-Functional and MAC- 316 Functional. The servers can be non-MAC-Functional, MAC-Aware, and 317 MAC-Functional. 319 A MAC-Functional client MUST be able to determine the level of MAC 320 functionality in the server. Likewise, a MAC-Functional server MUST 321 be able to determine whether or not a client is MAC-Functional. 323 3.5.1. Full Mode 325 The server and the client have mutually recognized MAC functionality 326 enabled, and full Labeled NFS functionality is extended over the 327 network between both client and server. 329 An example of an operation in full mode is as follows. On the 330 initial lookup, the client requests access to an object on the 331 server. It sends its process security context over to the server. 332 The server checks all relevant policies to determine if that process 333 context from that client is allowed to access the resource. Once 334 this has succeeded the object with its associated security 335 information is released to the client. Once the client receives the 336 object it determines if its policies allow the process running on the 337 client access to the object. 339 On subsequent operations where the client already has a handle for 340 the file, the order of enforcement is reversed. Since the client 341 already has the security context it may make an access decision 342 against its policy first. This enables the client to avoid sending 343 requests to the server that it knows will fail regardless of the 344 server's policy. If the client passes its policy checks then it 345 sends the request to the server where the client's process context is 346 used to determine if the server will release that resource to the 347 client. If both checks pass, the client is given the resource and 348 everything succeeds. 350 In the event that the client does not trust the server, it may opt to 351 use an alternate labeling mechanism regardless of the server's 352 ability to return security information. 354 3.5.2. Limited Server Mode 356 The server is MAC-Aware and the clients are MAC-Functional. The 357 server can store and transmit labels. It cannot enforce labels. The 358 server MUST inform clients when an object label changes for a file 359 the client has open. 361 In this mode, the server may not be aware of the format of any its 362 object labels. Indeed, it may service several different security 363 models at the same time. A client MUST process foreign labels as 364 discussed in Section 3.4. As with the Guest Mode, this mode's level 365 of trust can be degraded if non-MAC-functional clients have access to 366 the server. 368 3.5.3. Guest Mode 370 Only one of the server or client is MAC-Functional enabled. 372 In the case of the server only being MAC-Functional, the server 373 enforces its policy, and may selectively provide standard NFS 374 services to clients based on their authentication credentials and/or 375 associated network attributes (e.g., IP address, network interface) 376 according to security policy. The level of trust and access extended 377 to a client in this mode is configuration-specific. 379 In the case of the client only being MAC-Functional, the client MUST 380 operate as a standard NFSv4.2 client, and SHOULD selectively provide 381 processes access to servers based upon the security attributes of the 382 local process, and network attributes of the server, according to 383 policy. The client may also override default labeling of the remote 384 file system based upon these security attributes, or other labeling 385 methods such as mount point labeling. 387 In other words, Guest Mode is standard NFSv4.2 over the wire, with 388 the MAC-Functional system mapping the non-MAC-Functional system's 389 processes or objects to security labels based on other 390 characteristics in order to preserve its MAC guarantees. 392 3.6. Labeling 394 Implementations MUST validate security labels supplied over the 395 network to ensure that they are within a set of labels permitted from 396 a specific peer, and if not, reject them. Note that a system may 397 permit a different set of labels to be accepted from each peer. 399 3.6.1. Client Labeling 401 At the client, labeling semantics for NFS mounted file systems MUST 402 remain consistent with those for locally mounted file systems. In 403 particular, user-level labeling operations local to the client MUST 404 be enacted locally via existing APIs, to ensure compatibility and 405 consistency for applications and libraries. 407 Note that this does not imply any specific mechanism for conveying 408 labels over the network. 410 When an object is newly created by the client, it will calculate the 411 label for the object based on its policy. Once that is done it will 412 send the request to the server which has the ability to deny the 413 creation of the object with that label based on the server's policy. 414 In creating the file the server MUST ensure that the label is bound 415 to the object before the object becomes visible to the rest of the 416 system. This ensures that any access control or further labeling 417 decisions are correct for the object. 419 3.6.2. Server Labeling 421 The server MUST provide the capability for clients to retrieve 422 security labels on all exported file system objects where possible. 423 This includes cases where only in-core and/or read-only security 424 labels are available at the server for any of its exported file 425 systems. 427 The server MUST honor the ability for a client to specify the label 428 of an object on creation. If the server is MAC enabled it may choose 429 to reject the label specified by the client due to restrictions in 430 the server policy. The server SHOULD not attempt to find a suitable 431 label for an object in event of different labeling rules on its end. 432 The server is allowed to translate the label but SHOULD not change 433 the semantic meaning of the label. 435 3.7. Policy Enforcement 437 The MAC-Functional client determines if a process request is sent to 438 the remote server. Upon a successful response from the server, it 439 must use its own policies on the object's security labels to 440 determine if the process can be given access. The client SHOULD not 441 need to be cognizant if the server is either a Limited Server or 442 fully MAC-Functional. 444 3.7.1. Client Enforcement 446 The client MUST apply its own policy to remotely located objects, 447 using security labels for the objects obtained from the server. It 448 MUST be possible to configure the maximum length of time a client may 449 cache state regarding remote labels before re-validating that state 450 with the server. 452 If the server's policy changes, the client MUST flush all object 453 state back to the server. The server MUST ensure that any flushed 454 state received is consistent with current policy before committing it 455 to stable storage. 457 Any local security state associated with cached or delegated objects 458 MUST also be flushed back to the server when any other state of the 459 objects is required to be flushed back. 461 The implication here is that if the client holds a delegation on an 462 object, then it enforces policy to local changes based on the object 463 label it got from the server. When it tries to commit those changes 464 to the server, it SHOULD be prepared for the server to reject those 465 changes based on the policies of the server. 467 3.7.2. Server Enforcement 469 A MAC-Functional server MUST enforce its security policy over all 470 exported objects, for operations which originate both locally and 471 remotely. 473 Requests from authenticated clients MUST be processed using security 474 labels and credentials supplied by the client as if they originated 475 locally. 477 As with labeling, the system MUST also take into account any other 478 volatile client security state, such as a change in process security 479 context via dynamic transition. Access decisions SHOULD also be made 480 based upon the current client security label accessing the object, 481 rather than the security label which opened it, if different. 483 The server SHOULD recall delegation of an object if the object's 484 security label changes. 486 3.8. Namespace Access 488 The server SHOULD provide a means to authorize selective access to 489 the exported file system namespace based upon client credentials and 490 according to security policy. 492 This is a common requirement of MLS-enabled systems, which often need 493 to present selective views of namespaces based upon the clearances of 494 the subjects. 496 3.9. Upgrading Existing Server 498 Note that under the MAC model, all objects MUST have labels. 499 Therefore, if an existing server is upgraded to include Labeled NFS 500 support, then it is the responsibility of the security system to 501 define the behavior for existing objects. 503 4. Use Cases 505 MAC labeling is meant to allow NFSv4.2 to be deployed in site 506 configurable security schemes. The LFS and opaque data scheme allows 507 for flexibility to meet these different implementations. In this 508 section, we provide some examples of how NFSv4.2 could be deployed to 509 meet existing needs. This is not an exhaustive listing. 511 4.1. Full MAC labeling support for remotely mounted filesystems 513 In this case, we assume a local networked environment where the 514 servers and clients are under common administrative control. All 515 systems in this network have the same MAC implementation and 516 semantically identical MAC security labels for objects (i.e. labels 517 mean the same thing on different systems, even if the policies on 518 each system may differ to some extent). Clients will be able to 519 apply fine-grained MAC policy to objects accessed via NFS mounts, and 520 thus improve the overall consistency of MAC policy application within 521 this environment. 523 An example of this case would be where user home directories are 524 remotely mounted, and fine-grained MAC policy is implemented to 525 protect, for example, private user data from being read by malicious 526 web scripts running in the user's browser. With Labeled NFS, fine- 527 grained MAC labeling of the user's files will allow the MAC policy to 528 be implemented and provide the desired protection. 530 4.2. MAC labeling of virtual machine images stored on the network 532 Virtualization is now a commonly implemented feature of modern 533 operating systems, and there is a need to ensure that MAC security 534 policy is able to protect virtualized resources. A common 535 implementation scheme involves storing virtualized guest filesystems 536 on a networked server, which are then mounted remotely by guests upon 537 instantiation. In this case, there is a need to ensure that the 538 local guest kernel is able to access fine-grained MAC labels on the 539 remotely mounted filesystem so that its MAC security policy can be 540 applied. 542 4.3. International Traffic in Arms Regulations (ITAR) 544 The International Traffic in Arms Regulations (ITAR) is put forth by 545 the United States Department of State, Directorate of Defense and 546 Trade Controls. ITAR places strict requirements on the export and 547 thus access of defense articles and defense services. Organizations 548 that manage projects with articles and services deemed as within the 549 scope of ITAR must ensure the regulations are met. The regulations 550 require an assurance that ITAR information is accessed on a need-to- 551 know basis, thus requiring strict, centrally managed access controls 552 on items labeled as ITAR. Additionally, organizations must be able 553 to prove that the controls were adequately maintained and that 554 foreign nationals were not permitted access to these defense articles 555 or service. ITAR control applicability may be dynamic; information 556 may become subject to ITAR after creation (e.g., when the defense 557 implications of technology are recognized). 559 4.4. Legal Hold/eDiscovery 561 Increased cases of legal holds on electronic sources of information 562 (ESI) have resulted in organizations taking a pro-active approach to 563 reduce the scope and thus costs associated with these activities. 564 ESI Data Maps are increasing in use and require support in operating 565 systems to strictly manage access controls in the case of a legal 566 hold. The sizeable quantity of information involved in a legal 567 discovery request may preclude making a copy of the information to a 568 separate system that manages the legal hold on the copies; this 569 results in a need to enforce the legal hold on the original 570 information. 572 Organizations are taking steps to map out the sources of information 573 that are most likely to be placed under a legal hold, these efforts 574 result in ESI Data Maps. ESI Data Maps specify the Electronic Source 575 of Information and the requirements for sensitivity and criticality. 576 In the case of a legal hold, the ESI data map and labels can be used 577 to ensure the legal hold is properly enforced on the predetermined 578 set of information. An ESI data map narrows the scope of a legal 579 hold to the predetermined ESI. The information must then be 580 protected at a level of security of which the weight and 581 admissibility of that evidence may be proved in a court of law. 582 Current systems use application level controls and do not adequately 583 meet the requirements. Labels may be used in advance when an ESI 584 data map exercise is conducted with controls being applied at the 585 time of a hold or labels may be applied to data sets during an 586 eDiscovery exercise to ensure the data protections are adequate 587 during the legal hold period. 589 Note that this use case requires multi-attribute labels, as both 590 information sensitivity (e.g., to disclosure) and information 591 criticality (e.g., to continued business operations) need to be 592 captured. 594 4.5. Simple security label storage 596 In this case, a mixed and loosely administered network is assumed, 597 where nodes may be running a variety of operating systems with 598 different security mechanisms and security policies. It is desired 599 that network file servers be simply capable of storing and retrieving 600 MAC security labels for clients which use such labels. The Labeled 601 NFS protocol would be implemented here solely to enable transport of 602 MAC security labels across the network. It should be noted that in 603 such an environment, overall security cannot be as strongly enforced 604 as when the server is also enforcing, and that this scheme is aimed 605 at allowing MAC-capable clients to function with its MAC security 606 policy enabled rather than perhaps disabling it entirely. 608 4.6. Diskless Linux 610 A number of popular operating system distributions depend on a 611 mandatory access control (MAC) model to implement a kernel-enforced 612 security policy. Typically, such models assign particular roles to 613 individual processes, which limit or permit performing certain 614 operations on a set of files, directories, sockets, or other objects. 615 While the enforcing of the policy is typically a matter for the 616 diskless NFS client itself, the filesystem objects in such models 617 will typically carry MAC labels that are used to define policy on 618 access. These policies may, for instance, describe privilege 619 transitions that cannot be replicated using standard NFS ACL based 620 models. 622 For instance on a SYSV compatible system, if the 'init' process 623 spawns a process that attempts to start the 'NetworkManager' 624 executable, there may be a policy that sets up a role transition if 625 the 'init' process and 'NetworkManager' file labels match a 626 particular rule. Without this role transition, the process may find 627 itself having insufficient privileges to perform its primary job of 628 configuring network interfaces. 630 In setups of this type, a lot of the policy targets (such as sockets 631 or privileged system calls) are entirely local to the client. The 632 use of RPCSEC_GSSv3 ([4]) for enforcing compliance at the server 633 level is therefore of limited value. The ability to permanently 634 label files and have those labels read back by the client is, 635 however, crucial to the ability to enforce that policy. 637 4.7. Multi-Level Security 639 In a MLS system objects are generally assigned a sensitivity level 640 and a set of compartments. The sensitivity levels within the system 641 are given an order ranging from lowest to highest classification 642 level. Read access to an object is allowed when the sensitivity 643 level of the subject "dominates" the object it wants to access. This 644 means that the sensitivity level of the subject is higher than that 645 of the object it wishes to access and that its set of compartments is 646 a super-set of the compartments on the object. 648 The rest of the section will just use sensitivity levels. In general 649 the example is a client that wishes to list the contents of a 650 directory. The system defines the sensitivity levels as Unclassified 651 (U), Secret (S), and Top Secret (TS). The directory to be searched 652 is labeled Top Secret which means access to read the directory will 653 only be granted if the subject making the request is also labeled Top 654 Secret. 656 4.7.1. Full Mode - MAC-functional Client and Server 658 In the first part of this example a process on the client is running 659 at the Secret level. The process issues a readdir() system call 660 which enters the kernel. Before translating the readdir() system 661 call into a request to the NFSv4.2 server the host operating system 662 will consult the MAC module to see if the operation is allowed. 663 Since the process is operating at Secret and the directory to be 664 accessed is labeled Top Secret the MAC module will deny the request 665 and an error code is returned to user space. 667 Consider a second case where instead of running at Secret the process 668 is running at Top Secret. In this case the sensitivity of the 669 process is equal to or greater than that of the directory so the MAC 670 module will allow the request. Now the readdir() is translated into 671 the necessary NFSv4.2 call to the server. For the RPC request the 672 client is using the proper credential to assert to the server that 673 the process is running at Top Secret. 675 When the server receives the request it extracts the security label 676 from the RPC session and retrieves the label on the directory. The 677 server then checks with its MAC module if a Top Secret process is 678 allowed to read the contents of the Top Secret directory. Since this 679 is allowed by the policy then the server will return the appropriate 680 information back to the client. 682 In this example the policy on the client and server were both the 683 same. In the event that they were running different policies a 684 translation of the labels might be needed. In this case it could be 685 possible for a check to pass on the client and fail on the server. 686 The server may consider additional information when making its policy 687 decisions. For example the server could determine that a certain 688 subnet is only cleared for data up to Secret classification. If that 689 constraint was in place for the example above the client would still 690 succeed, but the server would fail since the client is asserting a 691 label that it is not able to use (Top Secret on a Secret network). 693 4.7.2. MAC-Functional Client 695 In these scenarios, the server is either non-MAC-Aware or MAC-Aware. 696 The actions of the client will depend whether it is configured to 697 treat the MAC-Aware server in the same manner as the non-MAC-Aware 698 one. I.e., does it utilize the approach presented in Section 3.5.3 699 or does it allow the MAC-Aware server to return labels? 701 With a client that is MAC-Functional and using the example in the 702 previous section, the result should be the same. The one difference 703 is that all decisions are made on the client. 705 4.7.2.1. MAC-Aware Server 707 A process on the client labeled Secret wishes to access a directory 708 labeled Top Secret on the server. This is denied since Secret does 709 not dominate Top Secret. Note that there will be NFSv4.2 operations 710 issued that return an object label for the client to process. 712 Note that in this scenario, all of the clients must be MAC- 713 Functional. A single client which does not do its access control 714 checks would violate the model. 716 4.7.2.2. Non-MAC-Aware Server 718 A process on the client labeled Secret wishes to access a directory 719 which the client's policies label as Top Secret on the server. This 720 is denied since Secret does not dominate Top Secret. Note that there 721 will not be NFSv4.2 operations issued. If the process had instead a 722 Top Secret process label, the client would issue NFSv4.2 operations 723 to access the directory on the server. 725 4.7.3. MAC-Functional Server 727 With a MAC-Functional server and a client which is not, the client 728 behaves as if it were in a normal NFSv4.2 environment. Since the 729 process on the client does not provide a security attribute the 730 server must define a mechanism for labeling all requests from a 731 client. Assume that the server is using the same criteria used in 732 the first example. The server sees the request as coming from a 733 subnet that is a Secret network. The server determines that all 734 clients on that subnet will have their requests labeled with Secret. 735 Since the directory on the server is labeled Top Secret and Secret 736 does not dominate Top Secret the server would fail the request with 737 NFS4ERR_ACCESS. 739 5. Security Considerations 741 5.1. Trust Needed for a Community 743 Labeled NFS is a transport mechanism for labels, a storage 744 requirement for labels, and a definition of how to interpret labels. 745 It defines the responsibilities of the client and the server in the 746 various permutations of being MAC-Functional. It does not however 747 dictate in any manner whether assumptions can be made about other 748 entities in the relationship. For example, it does not define 749 whether a MAC-Functional client can demand that a MAC-Aware server 750 only accept requests from other MAC-Functional clients. That is a 751 policy based in a MAC model and this document does not impose 752 policies on systems. 754 As the requirement is a policy, it can be met with the use of a MAC 755 model. Let L be a LFS which implements the Limited Server mode, 756 i.e., a MAC-Aware server connected to MAC-Functional clients. Then a 757 new LFS L' can be created which has the additional policy that the 758 MAC-Aware server MUST not accept any requests from a non-MAC- 759 Functional client. 761 5.2. Guest Modes 763 When either the client or server is operating in guest mode it is 764 important to realize that one side is not enforcing MAC protections. 765 Alternate methods are being used to handle the lack of MAC support 766 and care should be taken to identify and mitigate threats from 767 possible tampering outside of these methods. 769 5.3. MAC-Functional Client Configuration 771 We defined a MAC model as a access control decision made on a system 772 which normal users do not have the ability to override policies (see 773 Section 1). If the process labels are created solely on the client, 774 then if a malicious user has sufficient access on that client, the 775 Labeled NFS model is compromised. Note that this is no different 776 from: 778 o current implementations in which the server uses policies to 779 effectively determine the object label for requests from the 780 client, or 782 o local decisions made on the client by the MAC security system. 784 The server must either explicitly trust the client (as in [7]) or the 785 MAC model should enforce that users cannot override policies, perhaps 786 via a externally managed source. 788 Once the labels leave the client, they can be protected by the 789 transport mechanism as described in Section 3.3. 791 6. IANA Considerations 793 It is requested that IANA creates a registry of Label Formats to 794 describe the syntactic format and semantics of the security label 795 (see [2]). 797 7. References 799 7.1. Normative References 801 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 802 Levels", March 1997. 804 [2] Quigley, D. and J. Lu, "Registry Specification for MAC Security 805 Label Formats", draft-quigley-label-format-registry (work in 806 progress), 2011. 808 [3] Haynes, T., "NFS Version 4 Minor Version 2", 809 draft-ietf-nfsv4-minorversion2-08 (Work In Progress), 810 March 2011. 812 [4] Haynes, T. and N. Williams, "Remote Procedure Call (RPC) 813 Security Version 3", draft-williams-rpcsecgssv3 (work in 814 progress), 2011. 816 7.2. Informative References 818 [5] "Section 46.6. Multi-Level Security (MLS) of Deployment Guide: 819 Deployment, configuration and administration of Red Hat 820 Enterprise Linux 5, Edition 6", 2011. 822 [6] Smalley, S., "The Distributed Trusted Operating System (DTOS) 823 Home Page", 824 . 826 [7] Carter, J., "Implementing SELinux Support for NFS", 827 . 829 Appendix A. Acknowledgments 831 David Quigley was the early energy in motivating the entire Labeled 832 NFS effort. 834 James Morris, Jarrett Lu, and Stephen Smalley all were key 835 contributors to both early versions of this document and to many 836 conference calls. 838 Kathleen Moriarty provided the use cases for ITAR and Legal Hold/ 839 eDiscovery. 841 Dan Walsh provided use cases for Secure Virtualization, Sandboxing, 842 and NFS homedir labeling to handle process separation. 844 Trond Myklebust provided use cases for secure diskless NFS clients. 846 Both Nico Williams and Bryce Nordgren challenged assumptions during 847 the review processes. 849 Appendix B. RFC Editor Notes 851 [RFC Editor: please remove this section prior to publishing this 852 document as an RFC] 854 [RFC Editor: prior to publishing this document as an RFC, please 855 replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the 856 RFC number of this document] 858 Author's Address 860 Thomas Haynes (editor) 861 NetApp 862 9110 E 66th St 863 Tulsa, OK 74133 864 USA 866 Phone: +1 918 307 1415 867 Email: thomas@netapp.com