idnits 2.17.1 draft-ietf-nfsv4-labreqs-02.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: LNFS 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 'MUST not' in this paragraph: If the server is MAC-Functional and the client is not, the server MUST not accept security labels provided by the client, and only enforce its policy to exported objects. In the event that the client is MAC-Functional while the server is not then the client may deny access or fall back on other methods for providing security labeling. == 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 11, 2012) is 4361 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 (~~), 6 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 11, 2012 5 Expires: November 12, 2012 7 Requirements for Labeled NFS 8 draft-ietf-nfsv4-labreqs-02.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 12, 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. Full Mode . . . . . . . . . . . . . . . . . . . . . . 10 88 3.7.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . . 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. Guest Modes . . . . . . . . . . . . . . . . . . . . . . . 17 106 5.2. MAC-Functional Client Configuration . . . . . . . . . . . 17 107 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 108 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 109 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 110 7.2. Informative References . . . . . . . . . . . . . . . . . . 18 111 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18 112 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 19 113 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 115 1. Introduction 117 Mandatory Access Control (MAC) systems have been mainstreamed in 118 modern operating systems such as Linux (R), FreeBSD (R), and Solaris 119 (TM). MAC systems bind security attributes to subjects (processes) 120 and objects within a system. These attributes are used with other 121 information in the system to make access control decisions. 123 Access control models such as Unix permissions or Access Control 124 Lists are commonly referred to as Discretionary Access Control (DAC) 125 models. These systems base their access decisions on user identity 126 and resource ownership. In contrast MAC models base their access 127 control decisions on the label on the subject (usually a process) and 128 the object it wishes to access. These labels may contain user 129 identity information but usually contain additional information. In 130 DAC systems users are free to specify the access rules for resources 131 that they own. MAC models base their security decisions on a system 132 wide policy established by an administrator or organization which the 133 users do not have the ability to override. DAC systems offer no real 134 protection against malicious or flawed software due to each program 135 running with the full permissions of the user executing it. 136 Inversely MAC models can confine malicious or flawed software and 137 usually act at a finer granularity than their DAC counterparts. 139 People desire to use NFSv4 with these systems. A mechanism is 140 required to provide security attribute information to NFSv4 clients 141 and servers. This mechanism has the following requirements: 143 (1) Clients MUST be able to convey to the server the security 144 attribute of the subject making the access request. The server 145 may provide a mechanism to enforce MAC policy based on the 146 requesting subject's security attribute. 148 (2) Servers MUST be able to store and retrieve the security 149 attribute of exported files as requested by the client. 151 (3) Servers MUST provide a mechanism for notifying clients of 152 attribute changes of files on the server. 154 (4) Clients and Servers MUST be able to negotiate Label Formats and 155 provide a mechanism to translate between them as needed. 157 2. Definitions 158 Label Format Specifier (LFS): is an identifier used by the client to 159 establish the syntactic format of the security label and the 160 semantic meaning of its components. 162 Label Format Registry: is the IANA registry (see [2]) containing all 163 registered LFS along with references to the documents that 164 describe the syntactic format and semantics of the security label. 166 Policy Identifier (PI): is an optional part of the definition of a 167 Label Format Specifier which allows for clients and server to 168 identify specific security policies. 170 Object: is a passive resource within the system that we wish to be 171 protected. Objects can be entities such as files, directories, 172 pipes, sockets, and many other system resources relevant to the 173 protection of the system state. 175 Subject: is an active entity, usually a process, which is requesting 176 access to an object. 178 MAC-Aware: is a server which can transmit and store object labels. 180 MAC-Functional: is a client or server which is LNFS enabled. Such a 181 system can interpret labels and apply policies based on the 182 security system. 184 Multi-Level Security (MLS): is a traditional model where objects are 185 given a sensitivity level (Unclassified, Secret, Top Secret, etc) 186 and a category set [5]. 188 3. Requirements 190 The following initial requirements have been gathered from users, 191 developers, and from previous development efforts in this area such 192 as DTOS [6] and NSA's experimental NFSv3 enhancements [7]. 194 3.1. Portability & Interoperability 196 LNFS MUST be designed with portability in mind, to facilitate 197 implementations on any operating system that supports mandatory 198 access controls. 200 LNFS MUST be designed and developed to facilitate interoperability 201 between different LNFS implementations. 203 LNFS modifications to standard NFSv4.2 [3] implementations MUST not 204 adversely impact any existing interoperability of those 205 implementations. 207 3.2. Performance & Scalability 209 Security mechanisms often impact on system performance. LNFS SHOULD 210 be designed and implemented in a way which avoids significant 211 performance impact where possible. 213 As NFSv4.2 is designed for large-scale distributed networking, LNFS 214 SHOULD also be capable of scaling in a similar manner to underlying 215 implementations where possible. 217 LNFS SHOULD respond in a robust manner to system and network outages 218 associated with typical enterprise and Internet environments. At the 219 very least, LNFS SHOULD always operate in a fail-safe manner, so that 220 service disruptions do not cause or facilitate security 221 vulnerabilities. 223 3.3. Security Services 225 LNFS SHOULD ensure that the following security services are provided 226 for all NFSv4.2 messaging. These services may be provided by lower 227 layers even if NFS has to be aware of and leverage them: 229 o Authentication 231 o Integrity 233 o Privacy 235 Mechanisms and algorithms used in the provision of security services 236 MUST be configurable, so that appropriate levels of protection may be 237 flexibly specified per mandatory security policy. 239 Strong mutual authentication will be required between the server and 240 the client for Full Mode operation Section 3.5.1. 242 MAC security labels and any related security state SHOULD always be 243 protected by these security services when transferred over the 244 network; as SHOULD the binding of labels and state to associated 245 objects and subjects. 247 LNFS SHOULD support authentication on a context granularity so that 248 different contexts running on a client can use different 249 cryptographic keys and facilities. 251 3.4. Label Encoding, Label Format Specifiers, and Label Checking 252 Authorities 254 Encoding of MAC labels and attributes passed over the network MUST be 255 specified in a complete and unambiguous manner while maintaining the 256 flexibility of MAC implementations. To accomplish this the labels 257 MUST consist of an opaque component bound with a Label Format 258 Specifier (LFS). The LFS component provides a mechanism for 259 identifying the structure and semantics of the opaque component. 260 Meanwhile, the opaque component is the security label which will be 261 interpreted by the MAC models. 263 MAC models base access decisions on security attributes bound to 264 subjects and objects. With a given MAC model, all systems have 265 semantically coherent labeling - a security label MUST always mean 266 exactly the same thing on every system. While this may not be 267 necessary for simple MAC models it is recommended that most label 268 formats assigned an LFS incorporate this concept into their label 269 format. 271 LNFS MUST provide a means for servers and clients to identify their 272 LFS for the purposes of authorization, security service selection, 273 and security label interpretation. 275 A negotiation scheme SHOULD be provided, allowing systems from 276 different label formats to agree on how they will interpret or 277 translate each others labels. Multiple concurrent agreements may be 278 current between a server and a client. 280 All security labels and related security state transferred across the 281 network MUST be tagged with a valid LFS. 283 If the LFS supported on a system changes, it SHOULD renegotiate 284 agreements to reflect these changes. 286 If a system receives any security label or security state tagged with 287 an LFS it does not recognize or cannot interpret, it MUST reject that 288 label or state. 290 NFSv4.2 includes features which may cause a client to cross an LFS 291 boundary when accessing what appears to be a single file system. If 292 LFS negotiation is supported by the client and the server, the server 293 SHOULD negotiate a new, concurrent agreement with the client, acting 294 on behalf of the externally located source of the files. 296 LNFS SHOULD define an initial negotiation scheme with the primary 297 aims of simplicity and completeness. This is to facilitate practical 298 deployment of systems without being weighed down by complex and over- 299 generalized global schemes. Future extensibility SHOULD also be 300 taken into consideration. 302 3.5. Modes of Operation 304 In a LNFS client and server interaction, we can describe three modes 305 of operation: 307 1. Full 309 2. Limited Server 311 3. Guest 313 These modes arise from the level of MAC functionality in the clients 314 and servers. The clients can be non-MAC-Functional and MAC- 315 Functional. The servers can be non-MAC-Functional, MAC-Aware, and 316 MAC-Functional. 318 A MAC-Functional client MUST be able to determine the level of MAC 319 functionality in the server. Likewise, a MAC-Functional server MUST 320 be able to determine whether or not a client is MAC-Functional. 322 3.5.1. Full Mode 324 The server and the client have mutually recognized MAC functionality 325 enabled, and full LNFS functionality is extended over the network 326 between both client and server. 328 An example of an operation in full mode is as follows. On the 329 initial lookup, the client requests access to an object on the 330 server. It sends its process security context over to the server. 331 The server checks all relevant policies to determine if that process 332 context from that client is allowed to access the resource. Once 333 this has succeeded the object with its associated security 334 information is released to the client. Once the client receives the 335 object it determines if its policies allow the process running on the 336 client access to the object. 338 On subsequent operations where the client already has a handle for 339 the file, the order of enforcement is reversed. Since the client 340 already has the security context it may make an access decision 341 against its policy first. This enables the client to avoid sending 342 requests to the server that it knows will fail regardless of the 343 server's policy. If the client passes its policy checks then it 344 sends the request to the server where the client's process context is 345 used to determine if the server will release that resource to the 346 client. If both checks pass, the client is given the resource and 347 everything succeeds. 349 In the event that the client does not trust the server, it may opt to 350 use an alternate labeling mechanism regardless of the server's 351 ability to return security information. 353 3.5.2. Limited Server Mode 355 The server is MAC-Aware and the clients are MAC-Functional. The 356 server can store and transmit labels. It cannot enforce labels. The 357 server SHOULD inform clients when an object label changes for a file 358 the client has open. 360 In this mode, the server may not be aware of the format of any its 361 object labels. Indeed, it may service several different security 362 models at the same time. A client MUST process foreign labels as 363 discussed in Section 3.4. As with the Guest Mode, this mode's level 364 of trust can be degraded if non-MAC-functional clients have access to 365 the server. 367 3.5.3. Guest Mode 369 Only one of the server or client is MAC-Functional enabled. 371 In the case of the server only being MAC-Functional, the server 372 enforces its policy, and may selectively provide standard NFS 373 services to clients based on their authentication credentials and/or 374 associated network attributes (e.g., IP address, network interface) 375 according to security policy. The level of trust and access extended 376 to a client in this mode is configuration-specific. 378 In the case of the client only being MAC-Functional, the client MUST 379 operate as a standard NFSv4.2 client, and SHOULD selectively provide 380 processes access to servers based upon the security attributes of the 381 local process, and network attributes of the server, according to 382 policy. The client may also override default labeling of the remote 383 file system based upon these security attributes, or other labeling 384 methods such as mount point labeling. 386 In other words, Guest Mode is standard NFSv4.2 over the wire, with 387 the MAC-Functional system mapping the non-MAC-Functional system's 388 processes or objects to security labels based on other 389 characteristics in order to preserve its MAC guarantees. 391 3.6. Labeling 393 Implementations MUST validate security labels supplied over the 394 network to ensure that they are within a set of labels permitted from 395 a specific peer, and if not, reject them. Note that a system may 396 permit a different set of labels to be accepted from each peer. 398 3.6.1. Client Labeling 400 At the client, labeling semantics for NFS mounted file systems MUST 401 remain consistent with those for locally mounted file systems. In 402 particular, user-level labeling operations local to the client MUST 403 be enacted locally via existing APIs, to ensure compatibility and 404 consistency for applications and libraries. 406 Note that this does not imply any specific mechanism for conveying 407 labels over the network. 409 When an object is newly created by the client, it will calculate the 410 label for the object based on its policy. Once that is done it will 411 send the request to the server which has the ability to deny the 412 creation of the object with that label based on the server's policy. 413 In creating the file the server MUST ensure that the label is bound 414 to the object before the object becomes visible to the rest of the 415 system. This ensures that any access control or further labeling 416 decisions are correct for the object. 418 3.6.2. Server Labeling 420 The server MUST provide the capability for clients to retrieve 421 security labels on all exported file system objects where possible. 422 This includes cases where only in-core and/or read-only security 423 labels are available at the server for any of its exported file 424 systems. 426 The server MUST honor the ability for a client to specify the label 427 of an object on creation. If the server is MAC enabled it may choose 428 to reject the label specified by the client due to restrictions in 429 the server policy. The server SHOULD not attempt to find a suitable 430 label for an object in event of different labeling rules on its end. 431 The server is allowed to translate the label but SHOULD not change 432 the semantic meaning of the label. 434 3.7. Policy Enforcement 436 3.7.1. Full Mode 438 The server MUST enforce its security policy over all exported 439 objects, for operations which originate both locally and remotely. 441 Requests from authenticated clients MUST be processed using security 442 labels and credentials supplied by the client as if they originated 443 locally. 445 As with labeling, the system MUST also take into account any other 446 volatile client security state, such as a change in process security 447 context via dynamic transition. Access decisions SHOULD also be made 448 based upon the current client security label accessing the object, 449 rather than the security label which opened it, if different. 451 The client MUST apply its own policy to remotely located objects, 452 using security labels for the objects obtained from the server. It 453 MUST be possible to configure the maximum length of time a client may 454 cache state regarding remote labels before re-validating that state 455 with the server. 457 The server MUST recall delegation of an object if the object's 458 security label changes. 460 A mechanism MUST exist to allow the client to obtain access, and 461 labeling decisions from the server for locally cached and delegated 462 objects, so that it may apply the server's policy to these objects. 463 If the server's policy changes, the client MUST flush all object 464 state back to the server. The server MUST ensure that any flushed 465 state received is consistent with current policy before committing it 466 to stable storage. 468 Any local security state associated with cached or delegated objects 469 MUST also be flushed back to the server when any other state of the 470 objects is required to be flushed back. 472 3.7.2. Guest Mode 474 If the server is MAC-Functional and the client is not, the server 475 MUST not accept security labels provided by the client, and only 476 enforce its policy to exported objects. In the event that the client 477 is MAC-Functional while the server is not then the client may deny 478 access or fall back on other methods for providing security labeling. 480 3.8. Namespace Access 482 The server SHOULD provide a means to authorize selective access to 483 the exported file system namespace based upon client credentials and 484 according to security policy. 486 This is a common requirement of MLS-enabled systems, which often need 487 to present selective views of namespaces based upon the clearances of 488 the subjects. 490 3.9. Upgrading Existing Server 492 Note that under the MAC model, all objects MUST have labels. 493 Therefore, if an existing server is upgraded to include LNFS support, 494 then it is the responsibility of the security system to define the 495 behavior for existing objects. 497 4. Use Cases 499 MAC labeling is meant to allow NFSv4.2 to be deployed in site 500 configurable security schemes. The LFS and opaque data scheme allows 501 for flexibility to meet these different implementations. In this 502 section, we provide some examples of how NFSv4.2 could be deployed to 503 meet existing needs. This is not an exhaustive listing. 505 4.1. Full MAC labeling support for remotely mounted filesystems 507 In this case, we assume a local networked environment where the 508 servers and clients are under common administrative control. All 509 systems in this network have the same MAC implementation and 510 semantically identical MAC security labels for objects (i.e. labels 511 mean the same thing on different systems, even if the policies on 512 each system may differ to some extent). Clients will be able to 513 apply fine-grained MAC policy to objects accessed via NFS mounts, and 514 thus improve the overall consistency of MAC policy application within 515 this environment. 517 An example of this case would be where user home directories are 518 remotely mounted, and fine-grained MAC policy is implemented to 519 protect, for example, private user data from being read by malicious 520 web scripts running in the user's browser. With Labeled NFS, fine- 521 grained MAC labeling of the user's files will allow the MAC policy to 522 be implemented and provide the desired protection. 524 4.2. MAC labeling of virtual machine images stored on the network 526 Virtualization is now a commonly implemented feature of modern 527 operating systems, and there is a need to ensure that MAC security 528 policy is able to protect virtualized resources. A common 529 implementation scheme involves storing virtualized guest filesystems 530 on a networked server, which are then mounted remotely by guests upon 531 instantiation. In this case, there is a need to ensure that the 532 local guest kernel is able to access fine-grained MAC labels on the 533 remotely mounted filesystem so that its MAC security policy can be 534 applied. 536 4.3. International Traffic in Arms Regulations (ITAR) 538 The International Traffic in Arms Regulations (ITAR) is put forth by 539 the United States Department of State, Directorate of Defense and 540 Trade Controls. ITAR places strict requirements on the export and 541 thus access of defense articles and defense services. Organizations 542 that manage projects with articles and services deemed as within the 543 scope of ITAR must ensure the regulations are met. The regulations 544 require an assurance that ITAR information is accessed on a need-to- 545 know basis, thus requiring strict, centrally managed access controls 546 on items labeled as ITAR. Additionally, organizations must be able 547 to prove that the controls were adequately maintained and that 548 foreign nationals were not permitted access to these defense articles 549 or service. ITAR control applicability may be dynamic; information 550 may become subject to ITAR after creation (e.g., when the defense 551 implications of technology are recognized). 553 4.4. Legal Hold/eDiscovery 555 Increased cases of legal holds on electronic sources of information 556 (ESI) have resulted in organizations taking a pro-active approach to 557 reduce the scope and thus costs associated with these activities. 558 ESI Data Maps are increasing in use and require support in operating 559 systems to strictly manage access controls in the case of a legal 560 hold. The sizeable quantity of information involved in a legal 561 discovery request may preclude making a copy of the information to a 562 separate system that manages the legal hold on the copies; this 563 results in a need to enforce the legal hold on the original 564 information. 566 Organizations are taking steps to map out the sources of information 567 that are most likely to be placed under a legal hold, these efforts 568 result in ESI Data Maps. ESI Data Maps specify the Electronic Source 569 of Information and the requirements for sensitivity and criticality. 570 In the case of a legal hold, the ESI data map and labels can be used 571 to ensure the legal hold is properly enforced on the predetermined 572 set of information. An ESI data map narrows the scope of a legal 573 hold to the predetermined ESI. The information must then be 574 protected at a level of security of which the weight and 575 admissibility of that evidence may be proved in a court of law. 576 Current systems use application level controls and do not adequately 577 meet the requirements. Labels may be used in advance when an ESI 578 data map exercise is conducted with controls being applied at the 579 time of a hold or labels may be applied to data sets during an 580 eDiscovery exercise to ensure the data protections are adequate 581 during the legal hold period. 583 Note that this use case requires multi-attribute labels, as both 584 information sensitivity (e.g., to disclosure) and information 585 criticality (e.g., to continued business operations) need to be 586 captured. 588 4.5. Simple security label storage 590 In this case, a mixed and loosely administered network is assumed, 591 where nodes may be running a variety of operating systems with 592 different security mechanisms and security policies. It is desired 593 that network file servers be simply capable of storing and retrieving 594 MAC security labels for clients which use such labels. The LNFS 595 protocol would be implemented here solely to enable transport of MAC 596 security labels across the network. It should be noted that in such 597 an environment, overall security cannot be as strongly enforced as 598 when the server is also enforcing, and that this scheme is aimed at 599 allowing MAC-capable clients to function with its MAC security policy 600 enabled rather than perhaps disabling it entirely. 602 4.6. Diskless Linux 604 A number of popular operating system distributions depend on a 605 mandatory access control (MAC) model to implement a kernel-enforced 606 security policy. Typically, such models assign particular roles to 607 individual processes, which limit or permit performing certain 608 operations on a set of files, directories, sockets, or other objects. 609 While the enforcing of the policy is typically a matter for the 610 diskless NFS client itself, the filesystem objects in such models 611 will typically carry MAC labels that are used to define policy on 612 access. These policies may, for instance, describe privilege 613 transitions that cannot be replicated using standard NFS ACL based 614 models. 616 For instance on a SYSV compatible system, if the 'init' process 617 spawns a process that attempts to start the 'NetworkManager' 618 executable, there may be a policy that sets up a role transition if 619 the 'init' process and 'NetworkManager' file labels match a 620 particular rule. Without this role transition, the process may find 621 itself having insufficient privileges to perform its primary job of 622 configuring network interfaces. 624 In setups of this type, a lot of the policy targets (such as sockets 625 or privileged system calls) are entirely local to the client. The 626 use of RPCSEC_GSSv3 ([4]) for enforcing compliance at the server 627 level is therefore of limited value. The ability to permanently 628 label files and have those labels read back by the client is, 629 however, crucial to the ability to enforce that policy. 631 4.7. Multi-Level Security 633 In a MLS system objects are generally assigned a sensitivity level 634 and a set of compartments. The sensitivity levels within the system 635 are given an order ranging from lowest to highest classification 636 level. Read access to an object is allowed when the sensitivity 637 level of the subject "dominates" the object it wants to access. This 638 means that the sensitivity level of the subject is higher than that 639 of the object it wishes to access and that its set of compartments is 640 a super-set of the compartments on the object. 642 The rest of the section will just use sensitivity levels. In general 643 the example is a client that wishes to list the contents of a 644 directory. The system defines the sensitivity levels as Unclassified 645 (U), Secret (S), and Top Secret (TS). The directory to be searched 646 is labeled Top Secret which means access to read the directory will 647 only be granted if the subject making the request is also labeled Top 648 Secret. 650 4.7.1. Full Mode - MAC-functional Client and Server 652 In the first part of this example a process on the client is running 653 at the Secret level. The process issues a readdir() system call 654 which enters the kernel. Before translating the readdir() system 655 call into a request to the NFSv4.2 server the host operating system 656 will consult the MAC module to see if the operation is allowed. 657 Since the process is operating at Secret and the directory to be 658 accessed is labeled Top Secret the MAC module will deny the request 659 and an error code is returned to user space. 661 Consider a second case where instead of running at Secret the process 662 is running at Top Secret. In this case the sensitivity of the 663 process is equal to or greater than that of the directory so the MAC 664 module will allow the request. Now the readdir() is translated into 665 the necessary NFSv4.2 call to the server. For the RPC request the 666 client is using the proper credential to assert to the server that 667 the process is running at Top Secret. 669 When the server receives the request it extracts the security label 670 from the RPC session and retrieves the label on the directory. The 671 server then checks with its MAC module if a Top Secret process is 672 allowed to read the contents of the Top Secret directory. Since this 673 is allowed by the policy then the server will return the appropriate 674 information back to the client. 676 In this example the policy on the client and server were both the 677 same. In the event that they were running different policies a 678 translation of the labels might be needed. In this case it could be 679 possible for a check to pass on the client and fail on the server. 680 The server may consider additional information when making its policy 681 decisions. For example the server could determine that a certain 682 subnet is only cleared for data up to Secret classification. If that 683 constraint was in place for the example above the client would still 684 succeed, but the server would fail since the client is asserting a 685 label that it is not able to use (Top Secret on a Secret network). 687 4.7.2. MAC-Functional Client 689 In these scenarios, the server is either non-MAC-Aware or MAC-Aware. 690 The actions of the client will depend whether it is configured to 691 treat the MAC-Aware server in the same manner as the non-MAC-Aware 692 one. I.e., does it utilize the approach presented in Section 3.5.3 693 or does it allow the MAC-Aware server to return labels? 695 With a client that is MAC-Functional and using the example in the 696 previous section, the result should be the same. The one difference 697 is that all decisions are made on the client. 699 4.7.2.1. MAC-Aware Server 701 A process on the client labeled Secret wishes to access a directory 702 labeled Top Secret on the server. This is denied since Secret does 703 not dominate Top Secret. Note that there will be NFSv4.2 operations 704 issued that return an object label for the client to process. 706 Note that in this scenario, all of the clients must be MAC- 707 Functional. A single client which does not do its access control 708 checks would violate the model. 710 4.7.2.2. Non-MAC-Aware Server 712 A process on the client labeled Secret wishes to access a directory 713 which the client's policies label as Top Secret on the server. This 714 is denied since Secret does not dominate Top Secret. Note that there 715 will not be NFSv4.2 operations issued. If the process had instead a 716 Top Secret process label, the client would issue NFSv4.2 operations 717 to access the directory on the server. 719 4.7.3. MAC-Functional Server 721 With a MAC-Functional server and a client which is not, the client 722 behaves as if it were in a normal NFSv4.2 environment. Since the 723 process on the client does not provide a security attribute the 724 server must define a mechanism for labeling all requests from a 725 client. Assume that the server is using the same criteria used in 726 the first example. The server sees the request as coming from a 727 subnet that is a Secret network. The server determines that all 728 clients on that subnet will have their requests labeled with Secret. 729 Since the directory on the server is labeled Top Secret and Secret 730 does not dominate Top Secret the server would fail the request with 731 NFS4ERR_ACCESS. 733 5. Security Considerations 735 5.1. Guest Modes 737 When either the client or server is operating in guest mode it is 738 important to realize that one side is not enforcing MAC protections. 739 Alternate methods are being used to handle the lack of MAC support 740 and care should be taken to identify and mitigate threats from 741 possible tampering outside of these methods. 743 5.2. MAC-Functional Client Configuration 745 We defined a MAC model as a access control decision made on a system 746 which normal users do not have the ability to override policies (see 747 Section 1). If the process labels are created solely on the client, 748 then if a malicious user has sufficient access on that client, the 749 LNFS model is compromised. Note that this is no different from: 751 o current implementations in which the server uses policies to 752 effectively determine the object label for requests from the 753 client, or 755 o local decisions made on the client by the MAC security system. 757 The server must either explicitly trust the client (as in [7]) or the 758 MAC model should enforce that users cannot override policies, perhaps 759 via a externally managed source. 761 Once the labels leave the client, they can be protected by the 762 transport mechanism as described in Section 3.3. 764 6. IANA Considerations 766 It is requested that IANA creates a registry of Label Formats to 767 describe the syntactic format and semantics of the security label 768 (see [2]). 770 7. References 771 7.1. Normative References 773 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 774 Levels", March 1997. 776 [2] Quigley, D. and J. Lu, "Registry Specification for MAC Security 777 Label Formats", draft-quigley-label-format-registry (work in 778 progress), 2011. 780 [3] Haynes, T., "NFS Version 4 Minor Version 2", 781 draft-ietf-nfsv4-minorversion2-08 (Work In Progress), 782 March 2011. 784 [4] Haynes, T. and N. Williams, "Remote Procedure Call (RPC) 785 Security Version 3", draft-williams-rpcsecgssv3 (work in 786 progress), 2011. 788 7.2. Informative References 790 [5] "Section 46.6. Multi-Level Security (MLS) of Deployment Guide: 791 Deployment, configuration and administration of Red Hat 792 Enterprise Linux 5, Edition 6", 2011. 794 [6] Smalley, S., "The Distributed Trusted Operating System (DTOS) 795 Home Page", 796 . 798 [7] Carter, J., "Implementing SELinux Support for NFS", 799 . 801 Appendix A. Acknowledgments 803 David Quigley was the early energy in motivating the entire LNFS 804 effort. 806 James Morris, Jarrett Lu, and Stephen Smalley all were key 807 contributors to both early versions of this document and to many 808 conference calls. 810 Kathleen Moriarty provided the use cases for ITAR and Legal Hold/ 811 eDiscovery. 813 Dan Walsh provided use cases for Secure Virtualization, Sandboxing, 814 and NFS homedir labeling to handle process separation. 816 Trond Myklebust provided use cases for secure diskless NFS clients. 818 Both Nico Williams and Bryce Nordgren challenged assumptions during 819 the review processes. 821 Appendix B. RFC Editor Notes 823 [RFC Editor: please remove this section prior to publishing this 824 document as an RFC] 826 [RFC Editor: prior to publishing this document as an RFC, please 827 replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the 828 RFC number of this document] 830 Author's Address 832 Thomas Haynes (editor) 833 NetApp 834 9110 E 66th St 835 Tulsa, OK 74133 836 USA 838 Phone: +1 918 307 1415 839 Email: thomas@netapp.com