idnits 2.17.1 draft-quigley-nfsv4-labreqs-01.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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == 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 (February 08, 2012) is 4460 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) == Unused Reference: '2' is defined on line 705, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 708, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 712, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 716, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 719, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 722, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 5226 (ref. '5') (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 5661 (ref. '7') (Obsoleted by RFC 8881) Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFSv4 D. Quigley 3 Internet-Draft Consultant 4 Intended status: Standards Track J. Morris 5 Expires: August 11, 2012 Red Hat 6 J. Lu 7 Oracle 8 S. Smalley 9 NSA 10 T. Haynes, Ed. 11 NetApp 12 February 08, 2012 14 Requirements for Labeled NFS 15 draft-quigley-nfsv4-labreqs-01.txt 17 Abstract 19 This Internet-Draft outlines high-level requirements for the 20 integration of flexible Mandatory Access Control (MAC) functionality 21 into NFSv4.2. It describes the level of protections that should be 22 provided over protocol components and the basic structure of the 23 proposed system. It also gives a brief explanation of what kinds of 24 protections MAC systems offer. 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 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). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on August 11, 2012. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 This document may contain material from IETF Documents or IETF 65 Contributions published or made publicly available before November 66 10, 2008. The person(s) controlling the copyright in some of this 67 material may not have granted the IETF Trust the right to allow 68 modifications of such material outside the IETF Standards Process. 69 Without obtaining an adequate license from the person(s) controlling 70 the copyright in such materials, this document may not be modified 71 outside the IETF Standards Process, and derivative works of it may 72 not be created outside the IETF Standards Process, except to format 73 it for publication as an RFC or to translate it into languages other 74 than English. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 3.1. Portability & Interoperability . . . . . . . . . . . . . . 5 82 3.2. Performance & Scalability . . . . . . . . . . . . . . . . 6 83 3.3. Security Services . . . . . . . . . . . . . . . . . . . . 6 84 3.4. Label Encoding, Label Format Specifiers, and Labeling 85 Authorities . . . . . . . . . . . . . . . . . . . . . . . 6 86 3.5. Modes of Operation . . . . . . . . . . . . . . . . . . . . 8 87 3.5.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 8 88 3.5.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . . 8 89 3.6. Labeling . . . . . . . . . . . . . . . . . . . . . . . . . 9 90 3.6.1. Client Labeling . . . . . . . . . . . . . . . . . . . 9 91 3.6.2. Server Labeling . . . . . . . . . . . . . . . . . . . 9 92 3.7. Policy Enforcement . . . . . . . . . . . . . . . . . . . . 10 93 3.7.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 10 94 3.7.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . . 11 95 3.8. Namespace Access . . . . . . . . . . . . . . . . . . . . . 11 96 3.9. Upgrading Existing Server . . . . . . . . . . . . . . . . 11 97 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 98 4.1. Full MAC labeling support for remotely mounted 99 filesystems . . . . . . . . . . . . . . . . . . . . . . . 11 100 4.2. MAC labeling of virtual machine images stored on the 101 network . . . . . . . . . . . . . . . . . . . . . . . . . 12 102 4.3. International Traffic in Arms Regulations (ITAR) . . . . . 12 103 4.4. Legal Hold/eDiscovery . . . . . . . . . . . . . . . . . . 12 104 4.5. Simple security label storage . . . . . . . . . . . . . . 13 105 4.6. Diskless Linux . . . . . . . . . . . . . . . . . . . . . . 13 106 4.7. Multi-Level Security . . . . . . . . . . . . . . . . . . . 14 107 4.7.1. Full Mode - MAC functional Client and Server . . . . . 14 108 4.7.2. MAC functional Client . . . . . . . . . . . . . . . . 15 109 4.7.3. MAC functional Server . . . . . . . . . . . . . . . . 15 110 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 111 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 112 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 113 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 114 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 115 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 17 116 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 17 117 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 119 1. Introduction 121 Mandatory Access Control (MAC) systems have been mainstreamed in 122 modern operating systems such as Linux (R), FreeBSD (R), Solaris 123 (TM), and Windows Vista (R). MAC systems bind security attributes to 124 subjects (processes) and objects within a system. These attributes 125 are used with other information in the system to make access control 126 decisions. 128 Access control models such as Unix permissions or Access Control 129 Lists are commonly referred to as Discretionary Access Control (DAC) 130 models. These systems base their access decisions on user identity 131 and resource ownership. In contrast MAC models base their access 132 control decisions on the label on the subject (usually a process) and 133 the object it wishes to access. These labels may contain user 134 identity information but usually contain additional information. In 135 DAC systems users are free to specify the access rules for resources 136 that they own. MAC models base their security decisions on a system 137 wide policy established by an administrator or organization which the 138 users do not have the ability to override. DAC systems offer no real 139 protection against malicious or flawed software due to each program 140 running with the full permissions of the user executing it. 141 Inversely MAC models can confine malicious or flawed software and 142 usually act at a finer granularity than their DAC counterparts. 144 People desire to use NFSv4 with these systems. A mechanism is 145 required to provide security attribute information to NFSv4 clients 146 and servers. This mechanism has the following requirements: 148 (1) Clients must be able to convey to the server the security 149 attribute of the subject making the access request. The server 150 may provide a mechanism to enforce MAC policy based on the 151 requesting subject's security attribute. 153 (2) Server must be able to store and retrieve the security attribute 154 of exported files as requested by the client. 156 (3) Server must provide a mechanism for notifying clients of 157 attribute changes of files on the server. 159 (4) Clients and Servers must be able to negotiate Label Formats and 160 provide a mechanism to translate between them as needed. 162 2. Definitions 163 Label Format Specifier (LFS): is an identifier used by the client to 164 establish the syntactic format of the security label and the 165 semantic meaning of its components. These specifiers exist in a 166 registry associated with documents describing the format and 167 semantics of the label. 169 Label Format Registry: is the IANA registry containing all 170 registered LFS along with references to the documents that 171 describe the syntactic format and semantics of the security label. 173 Policy Identifier (PI): is an optional part of the definition of a 174 Label Format Specifier which allows for clients and server to 175 identify specific security policies. 177 Object: is a passive resource within the system that we wish to be 178 protected. Objects can be entities such as files, directories, 179 pipes, sockets, and many other system resources relevant to the 180 protection of the system state. 182 Subject: A subject is an active entity usually a process which is 183 requesting access to an object. 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 [8]. 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 [9] and NSA's experimental NFSv3 enhancements [10]. 195 3.1. Portability & Interoperability 197 LNFS must be designed with portability in mind, to facilitate 198 implementations on any operating system that supports mandatory 199 access controls. 201 LNFS must be designed and developed to facilitate interoperability 202 between different LNFS implementations. 204 LNFS modifications to standard NFSv4.2 implementations must not 205 adversely impact any existing interoperability of those 206 implementations. 208 3.2. Performance & Scalability 210 Security mechanisms often impact on system performance. LNFS should 211 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, LNFS 215 should also be capable of scaling in a similar manner to underlying 216 implementations where possible. 218 LNFS should be respond in a robust manner to system and network 219 outages associated with typical enterprise and Internet environments. 220 At the very least, LNFS should always operate in a fail-safe manner, 221 so that service disruptions do not cause or facilitate security 222 vulnerabilities. 224 3.3. Security Services 226 LNFS should ensure that the following security services are provided 227 for all NFSv4.2 messaging. These services may be provided by lower 228 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 must always be 244 protected by these security services when transferred over the 245 network; as must the binding of labels and state to associated 246 objects and subjects. 248 LNFS should support authentication on a context granularity so that 249 different contexts running on a client can use different 250 cryptographic keys and facilities. 252 3.4. Label Encoding, Label Format Specifiers, and Labeling 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 should consist of an opaque component bound with a Label Format 258 Specifier (LFS). The opaque component consists of the label which 259 will be interpreted by the MAC model on the other end while the LFS 260 provides a mechanism for identifying the structure and semantics of 261 the label's components. 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 of a system changes, it should renegotiate agreements to 284 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 LNFS must cater for two potentially concurrent operating modes, 305 depending on the state of MAC functionality: 307 3.5.1. Full Mode 309 Both the server and the client have MAC functionality enabled, and 310 full LNFS functionality is extended over the network between both 311 client and server. 313 An example of an operation in full mode is as follows. On the 314 initial lookup, the client requests access to an object on the 315 server. It sends its process security context over to the server. 316 The server checks all relevant local policies to determine if that 317 process context from that client is allowed to access the resource. 318 Once this has succeeded the object with its associated security 319 information is released to the client. Once the client receives the 320 object it determines if its local policy allows the process running 321 on the client access to the object. 323 On subsequent operations where the client already has a handle for 324 the file, the order of enforcement is reversed. Since the client 325 already has the security context it may make an access decision 326 against its local policy first. This enables the client to avoid 327 sending requests to the server that it knows will fail regardless of 328 the server's policy. If the client passes the local policy check 329 then it sends the request to the server where the client's process 330 context is used to determine if the server will release that resource 331 to the client. If both checks pass, the client is given the resource 332 and everything succeeds. 334 In the event that the client does not trust the server, it may opt to 335 use an alternate labeling mechanism regardless of the server's 336 ability to return security information. 338 3.5.2. Guest Mode 340 Only one of the server or client has MAC functionality enabled. 342 In the case of the server only having MAC functionality enabled, the 343 server locally enforces its policy, and may selectively provide 344 standard NFS services to clients based on their authentication 345 credentials and/or associated network attributes (e.g. IP address, 346 network interface) according to security policy. The level of trust 347 and access extended to a client in this mode is configuration- 348 specific. 350 In the case of the client only having MAC functionality enabled, the 351 client must operate as a standard NFSv4.2 client, and should 352 selectively provide processes access to servers based upon the 353 security attributes of the local process, and network attributes of 354 the server, according to policy. The client may also override 355 default labeling of the remote file system based upon these security 356 attributes, or other labeling methods such as mount point labeling. 358 In other words, Guest Mode is standard NFSv4.2 over the wire, with 359 the MAC-aware system mapping the MAC-unaware system's processes or 360 objects to security labels based on other characteristics in order to 361 preserve its local MAC guarantees. 363 3.6. Labeling 365 Implementations must validate security labels supplied over the 366 network to ensure that they are within a set of labels permitted from 367 a specific peer, and if not, reject them. Note that a system may 368 permit a different set of labels to be accepted from each peer. 370 3.6.1. Client Labeling 372 At the client, labeling semantics for NFS mounted file systems must 373 remain consistent with those for locally mounted file systems. In 374 particular, user-level labeling operations local to the client must 375 be enacted locally via existing APIs, to ensure compatibility and 376 consistency for applications and libraries. 378 Note that this does not imply any specific mechanism for conveying 379 labels over the network. 381 When an object is newly created by the client, it will calculate the 382 label for the object based on its local policy. Once that is done it 383 will send the request to the server which has the ability to deny the 384 creation of the object with that label based on the server's policy. 385 In creating the file the server must ensure that the label is bound 386 to the object before the object becomes visible to the rest of the 387 system. This ensures that any access control or further labeling 388 decisions are correct for the object. 390 3.6.2. Server Labeling 392 The server must provide the capability for clients to retrieve 393 security labels on all exported file system objects where possible. 394 This includes cases where only in-core and/or read-only security 395 labels are available at the server for any of its exported file 396 systems. 398 The server must honor the ability for a client to specify the label 399 of an object on creation. If the server is MAC enabled it may choose 400 to reject the label specified by the client due to restrictions in 401 the server policy. The server should not attempt to find a suitable 402 label for an object in event of different labeling rules on its end. 403 The server is allowed to translate the label but should not change 404 the semantic meaning of the label. 406 3.7. Policy Enforcement 408 3.7.1. Full Mode 410 The server must enforce its local security policy over all exported 411 objects, for operations which originate both locally and remotely. 413 Requests from authenticated clients must be processed using security 414 labels and credentials supplied by the client as if they originated 415 locally. 417 As with labeling, the system must also take into account any other 418 volatile client security state, such as a change in process security 419 context via dynamic transition. Access decisions should also be made 420 based upon the current client security label accessing the object, 421 rather than the security label which opened it, if different. 423 The client must apply its own policy to remotely located objects, 424 using security labels for the objects obtained from the server. It 425 must be possible to configure the maximum length of time a client may 426 cache state regarding remote labels before re-validating that state 427 with the server. 429 The server must recall delegation of an object if the object's 430 security label changes. 432 A mechanism must exist to allow the client to obtain access, and 433 labeling decisions from the server for locally cached and delegated 434 objects, so that it may apply the server's policy to these objects. 435 If the server's policy changes, the client must flush all object 436 state back to the server. The server must ensure that any flushed 437 state received is consistent with current policy before committing it 438 to stable storage. 440 Any local security state associated with cached or delegated objects 441 must also be flushed back to the server when any other state of the 442 objects is required to be flushed back. 444 3.7.2. Guest Mode 446 If the server is MAC aware and the client is not, the server must not 447 accept security labels provided by the client, and only enforce its 448 local policy to exported objects. In the event that the client is 449 MAC aware while the server is not then the client may deny access or 450 fall back on other methods for providing security labeling. 452 3.8. Namespace Access 454 The server should provide a means to authorize selective access to 455 the exported file system namespace based upon client credentials and 456 according to security policy. 458 This is a common requirement of MLS-enabled systems, which often need 459 to present selective views of namespaces based upon the clearances of 460 the subjects. 462 3.9. Upgrading Existing Server 464 Note that under the MAC model, all objects must have labels. 465 Therefore, if an existing server is upgraded to include LNFS support, 466 then it is the responsibility of the security system to define the 467 behavior for existing objects. For example, if the security system 468 is LFS 0, which means the server just stores and returns labels, then 469 existing files should return labels which are set to an empty value. 471 4. Use Cases 473 MAC labeling is meant to allow NFSv4.2 to be deployed in site 474 configurable security schemes. The LFS and opaque data scheme allows 475 for flexibility to meet these different implementations. In this 476 section, we provide some examples of how NFSv4.2 could be deployed to 477 meet existing needs. This is not an exhaustive listing. 479 4.1. Full MAC labeling support for remotely mounted filesystems 481 In this case, we assume a local networked environment where the 482 servers and clients are under common administrative control. All 483 systems in this network have the same MAC implementation and 484 semantically identical MAC security labels for objects (i.e. labels 485 mean the same thing on different systems, even if the policies on 486 each system may differ to some extent). Clients will be able to 487 apply fine-grained MAC policy to objects accessed via NFS mounts, and 488 thus improve the overall consistency of MAC policy application within 489 this environment. 491 An example of this case would be where user home directories are 492 remotely mounted, and fine-grained MAC policy is implemented to 493 protect, for example, private user data from being read by malicious 494 web scripts running in the user's browser. With Labeled NFS, fine- 495 grained MAC labeling of the user's files will allow the local MAC 496 policy to be implemented and provide the desired protection. 498 4.2. MAC labeling of virtual machine images stored on the network 500 Virtualization is now a commonly implemented feature of modern 501 operating systems, and there is a need to ensure that MAC security 502 policy is able to to protect virtualized resources. A common 503 implementation scheme involves storing virtualized guest filesystems 504 on a networked server, which are then mounted remotely by guests upon 505 instantiation. In this case, there is a need to ensure that the 506 local guest kernel is able to access fine-grained MAC labels on the 507 remotely mounted filesystem so that its MAC security policy can be 508 applied. 510 4.3. International Traffic in Arms Regulations (ITAR) 512 The International Traffic in Arms Regulations (ITAR) is put forth by 513 the United States Department of State, Directorate of Defense and 514 Trade Controls. ITAR places strict requirements on the export and 515 thus access of defense articles and defense services. Organizations 516 that manage projects with articles and services deemed as within the 517 scope of ITAR must ensure the regulations are met. The regulations 518 require an assurance that ITAR information is accessed on a need-to- 519 know basis, thus requiring strict, centrally managed access controls 520 on items labeled as ITAR. Additionally, organizations must be able 521 to prove that the controls were adequately maintained and that 522 foreign nationals were not permitted access to these defense articles 523 or service. ITAR control applicability may be dynamic; information 524 may become subject to ITAR after creation (e.g., when the defense 525 implications of technology are recognized). 527 4.4. Legal Hold/eDiscovery 529 Increased cases of legal holds on electronic sources of information 530 (ESI) have resulted in organizations taking a pro-active approach to 531 reduce the scope and thus costs associated with these activities. 532 ESI Data Maps are increasing in use and require support in operating 533 systems to strictly manage access controls in the case of a legal 534 hold. The sizeable quantity of information involved in a legal 535 discovery request may preclude making a copy of the information to a 536 separate system that manages the legal hold on the copies; this 537 results in a need to enforce the legal hold on the original 538 information. 540 Organizations are taking steps to map out the sources of information 541 that are most likely to be placed under a legal hold, these efforts 542 result in ESI Data Maps. ESI Data Maps specify the Electronic Source 543 of Information and the requirements for sensitivity and criticality. 544 In the case of a legal hold, the ESI data map and labels can be used 545 to ensure the legal hold is properly enforced on the predetermined 546 set of information. An ESI data map narrows the scope of a legal 547 hold to the predetermined ESI. The information must then be 548 protected at a level of security of which the weight and 549 admissibility of that evidence may be proved in a court of law. 550 Current systems use application level controls and do not adequately 551 meet the requirements. Labels may be used in advance when an ESI 552 data map exercise is conducted with controls being applied at the 553 time of a hold or labels may be applied to data sets during an 554 eDiscovery exercise to ensure the data protections are adequate 555 during the legal hold period. 557 Note that this use case requires multi-attribute labels, as both 558 information sensitivity (e.g., to disclosure) and information 559 criticality (e.g., to continued business operations) need to be 560 captured. 562 4.5. Simple security label storage 564 In this case, a mixed and loosely administered network is assumed, 565 where nodes may be running a variety of operating systems with 566 different security mechanisms and security policies. It is desired 567 that network file servers be simply capable of storing and retrieving 568 MAC security labels for clients which use such labels. The Labeled 569 NFS protocol would be implemented here solely to enable transport of 570 MAC security labels across the network. It should be noted that in 571 such an environment, overall security cannot be as strongly enforced 572 as in case (a), and that this scheme is aimed at allowing MAC-capable 573 clients to function with local MAC security policy enabled rather 574 than perhaps disabling it entirely. 576 4.6. Diskless Linux 578 A number of popular operating system distributions depend on a 579 mandatory access control (MAC) model to implement a kernel-enforced 580 security policy. Typically, such models assign particular roles to 581 individual processes, which limit or permit performing certain 582 operations on a set of files, directories, sockets, or other objects. 583 While the enforcing of the policy is typically a matter for the 584 diskless NFS client itself, the filesystem objects in such models 585 will typically carry MAC labels that are used to define policy on 586 access. These policies may, for instance, describe privilege 587 transitions that cannot be replicated using standard NFS ACL based 588 models. 590 For instance on a SYSV compatible system, if the 'init' process 591 spawns a process that attempts to start the 'NetworkManager' 592 executable, there may be a policy that sets up a role transition if 593 the 'init' process and 'NetworkManager' file labels match a 594 particular rule. Without this role transition, the process may find 595 itself having insufficient privileges to perform its primary job of 596 configuring network interfaces. 598 In setups of this type, a lot of the policy targets (such as sockets 599 or privileged system calls) are entirely local to the client. The 600 use of RPCSEC_GSSv3 for enforcing compliance at the server level is 601 therefore of limited value. The ability to permanently label files 602 and have those labels read back by the client is, however, crucial to 603 the ability to enforce that policy. 605 4.7. Multi-Level Security 607 In a MLS system objects are generally assigned a sensitivity level 608 and a set of compartments. The sensitivity levels within the system 609 are given an order ranging from lowest to highest classification 610 level. Read access to an object is allowed when the sensitivity 611 level of the subject "dominates" the object it wants to access. This 612 means that the sensitivity level of the subject is higher than that 613 of the object it wishes to access and that its set of compartments is 614 a super-set of the compartments on the object. 616 The rest of the section will just use sensitivity levels. In general 617 the example is a client that wishes to list the contents of a 618 directory. The system defines the sensitivity levels as Unclassified 619 (U), Secret (S), and Top Secret (TS). The directory to be searched 620 is labeled Top Secret which means access to read the directory will 621 only be granted if the subject making the request is also labeled Top 622 Secret. 624 4.7.1. Full Mode - MAC functional Client and Server 626 In the first part of this example a process on the client is running 627 at the Secret level. The process issues a readdir system call which 628 enters the kernel. Before translating the readdir system call into a 629 request to the NFSv4.2 server the host operating system will consult 630 the MAC module to see if the operation is allowed. Since the process 631 is operating at Secret and the directory to be accessed is labeled 632 Top Secret the MAC module will deny the request and an error code is 633 returned to user space. 635 Consider a second case where instead of running at Secret the process 636 is running at Top Secret. In this case the sensitivity of the 637 process is equal to or greater than that of the directory so the MAC 638 module will allow the request. Now the readdir is translated into 639 the necessary NFSv4.2 call to the server. For the RPC request the 640 client is using the proper credential to assert to the server that 641 the process is running at Top Secret. 643 When the server receives the request it extracts the security label 644 from the RPC session and retrieves the label on the directory. The 645 server then checks with its MAC module if a Top Secret process is 646 allowed to read the contents of the Top Secret directory. Since this 647 is allowed by the policy then the server will return the appropriate 648 information back to the client. 650 In this example the policy on the client and server were both the 651 same. In the event that they were running different policies a 652 translation of the labels might be needed. In this case it could be 653 possible for a check to pass on the client and fail on the server. 654 The server may consider additional information when making its policy 655 decisions. For example the server could determine that a certain 656 subnet is only cleared for data up to Secret classification. If that 657 constraint was in place for the example above the client would still 658 succeed, but the server would fail since the client is asserting a 659 label that it is not able to use (Top Secret on a Secret network). 661 4.7.2. MAC functional Client 663 With a client that is MAC functional and a server which is not, this 664 example is identical to the first part of the previous example. A 665 process on the client labeled Secret wishes to access a Top Secret 666 directory. As in the previous example, this is denied since Secret 667 does not dominate Top Secret. If the process were operating at Top 668 Secret it would pass the local access control check and the NFSv4.2 669 operation would proceed as in a normal NFSv4.2 environment. 671 4.7.3. MAC functional Server 673 With a MAC functional server and a client which is not, the client 674 behaves as if it were in a normal NFSv4.2 environment. Since the 675 process on the client does not provide a security attribute the 676 server must define a mechanism for labeling all requests from a 677 client. Assume that the server is using the same criteria used in 678 the first example. The server sees the request as coming from a 679 subnet that is a Secret network. The server determines that all 680 clients on that subnet will have their requests labeled with Secret. 681 Since the directory on the server is labeled Top Secret and Secret 682 does not dominate Top Secret the server would fail the request with 683 NFS4ERR_ACCESS. 685 5. Security Considerations 687 When either the client or server is operating in guest mode it is 688 important to realize that one side is not enforcing MAC protections. 689 Alternate methods are being used to handle the lack of MAC support 690 and care should be taken to identify and mitigate threats from 691 possible tampering outside of these methods. 693 6. IANA Considerations 695 It is requested that IANA creates a registry of Label Formats to 696 describe the syntactic format and semantics of the security label. 698 7. References 700 7.1. Normative References 702 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 703 Levels", March 1997. 705 [2] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 706 Specification", RFC 2203, September 1997. 708 [3] Haynes, T. and N. Williams, "Remote Procedure Call (RPC) 709 Security Version 3", draft-williams-rpcsecgssv3 (work in 710 progress), 2011. 712 [4] Quigley, D. and J. Lu, "Registry Specification for MAC Security 713 Label Formats", draft-quigley-label-format-registry (work in 714 progress), 2011. 716 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 717 Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 719 [6] Eisler, M., "XDR: External Data Representation Standard", 720 RFC 4506, May 2006. 722 [7] Shepler, S., Eisler, M., and D. Noveck, "Network File System 723 (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, 724 January 2010. 726 7.2. Informative References 728 [8] "Section 46.6. Multi-Level Security (MLS) of Deployment Guide: 729 Deployment, configuration and administration of Red Hat 730 Enterprise Linux 5, Edition 6", 2011. 732 [9] Smalley, S., "The Distributed Trusted Operating System (DTOS) 733 Home Page", 734 . 736 [10] Carter, J., "Implementing SELinux Support for NFS", 737 . 739 Appendix A. Acknowledgments 741 Kathleen Moriarty provided the use cases for ITAR and Legal Hold/ 742 eDiscovery. 744 Dan Walsh provided use cases for Secure Virtualization, Sandboxing, 745 and NFS homedir labeling to handle process separation. 747 Trond Myklebust provided use cases for secure diskless NFS clients. 749 Appendix B. RFC Editor Notes 751 [RFC Editor: please remove this section prior to publishing this 752 document as an RFC] 754 [RFC Editor: prior to publishing this document as an RFC, please 755 replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the 756 RFC number of this document] 758 Authors' Addresses 760 David Quigley 761 Consultant 763 Email: dpquigl@davequigley.com 765 James Morris 766 Red Hat, Inc. 768 Email: jmorris@namei.org 770 Jarrett Lu 771 Oracle 773 Email: jarrett.lu@oracle.com 774 Stephen Smalley 775 National Security Agency 777 Email: sds@tycho.nsa.gov 779 Thomas Haynes (editor) 780 NetApp 781 9110 E 66th St 782 Tulsa, OK 74133 783 USA 785 Phone: +1 918 307 1415 786 Email: thomas@netapp.com