idnits 2.17.1 draft-ietf-nfsv4-labreqs-00.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 (March 29, 2012) is 4383 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 698, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 701, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 705, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 709, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 712, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 715, 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 T. Haynes, Ed. 3 Internet-Draft NetApp 4 Intended status: Standards Track March 29, 2012 5 Expires: September 30, 2012 7 Requirements for Labeled NFS 8 draft-ietf-nfsv4-labreqs-00.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 September 30, 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 Labeling 78 Authorities . . . . . . . . . . . . . . . . . . . . . . . 6 79 3.5. Modes of Operation . . . . . . . . . . . . . . . . . . . . 8 80 3.5.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 8 81 3.5.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . . 8 82 3.6. Labeling . . . . . . . . . . . . . . . . . . . . . . . . . 9 83 3.6.1. Client Labeling . . . . . . . . . . . . . . . . . . . 9 84 3.6.2. Server Labeling . . . . . . . . . . . . . . . . . . . 9 85 3.7. Policy Enforcement . . . . . . . . . . . . . . . . . . . . 10 86 3.7.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 10 87 3.7.2. Guest Mode . . . . . . . . . . . . . . . . . . . . . . 11 88 3.8. Namespace Access . . . . . . . . . . . . . . . . . . . . . 11 89 3.9. Upgrading Existing Server . . . . . . . . . . . . . . . . 11 90 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 4.1. Full MAC labeling support for remotely mounted 92 filesystems . . . . . . . . . . . . . . . . . . . . . . . 11 93 4.2. MAC labeling of virtual machine images stored on the 94 network . . . . . . . . . . . . . . . . . . . . . . . . . 12 95 4.3. International Traffic in Arms Regulations (ITAR) . . . . . 12 96 4.4. Legal Hold/eDiscovery . . . . . . . . . . . . . . . . . . 12 97 4.5. Simple security label storage . . . . . . . . . . . . . . 13 98 4.6. Diskless Linux . . . . . . . . . . . . . . . . . . . . . . 13 99 4.7. Multi-Level Security . . . . . . . . . . . . . . . . . . . 14 100 4.7.1. Full Mode - MAC functional Client and Server . . . . . 14 101 4.7.2. MAC functional Client . . . . . . . . . . . . . . . . 15 102 4.7.3. MAC functional Server . . . . . . . . . . . . . . . . 15 103 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 104 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 105 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 106 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 107 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 108 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 17 109 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 17 110 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 112 1. Introduction 114 Mandatory Access Control (MAC) systems have been mainstreamed in 115 modern operating systems such as Linux (R), FreeBSD (R), Solaris 116 (TM), and Windows Vista (R). MAC systems bind security attributes to 117 subjects (processes) and objects within a system. These attributes 118 are used with other information in the system to make access control 119 decisions. 121 Access control models such as Unix permissions or Access Control 122 Lists are commonly referred to as Discretionary Access Control (DAC) 123 models. These systems base their access decisions on user identity 124 and resource ownership. In contrast MAC models base their access 125 control decisions on the label on the subject (usually a process) and 126 the object it wishes to access. These labels may contain user 127 identity information but usually contain additional information. In 128 DAC systems users are free to specify the access rules for resources 129 that they own. MAC models base their security decisions on a system 130 wide policy established by an administrator or organization which the 131 users do not have the ability to override. DAC systems offer no real 132 protection against malicious or flawed software due to each program 133 running with the full permissions of the user executing it. 134 Inversely MAC models can confine malicious or flawed software and 135 usually act at a finer granularity than their DAC counterparts. 137 People desire to use NFSv4 with these systems. A mechanism is 138 required to provide security attribute information to NFSv4 clients 139 and servers. This mechanism has the following requirements: 141 (1) Clients must be able to convey to the server the security 142 attribute of the subject making the access request. The server 143 may provide a mechanism to enforce MAC policy based on the 144 requesting subject's security attribute. 146 (2) Server must be able to store and retrieve the security attribute 147 of exported files as requested by the client. 149 (3) Server must provide a mechanism for notifying clients of 150 attribute changes of files on the server. 152 (4) Clients and Servers must be able to negotiate Label Formats and 153 provide a mechanism to translate between them as needed. 155 2. Definitions 156 Label Format Specifier (LFS): is an identifier used by the client to 157 establish the syntactic format of the security label and the 158 semantic meaning of its components. These specifiers exist in a 159 registry associated with documents describing the format and 160 semantics of the label. 162 Label Format Registry: is the IANA registry 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: A subject is an active entity usually a process which is 176 requesting access to an object. 178 Multi-Level Security (MLS): is a traditional model where objects are 179 given a sensitivity level (Unclassified, Secret, Top Secret, etc) 180 and a category set [8]. 182 3. Requirements 184 The following initial requirements have been gathered from users, 185 developers, and from previous development efforts in this area such 186 as DTOS [9] and NSA's experimental NFSv3 enhancements [10]. 188 3.1. Portability & Interoperability 190 LNFS must be designed with portability in mind, to facilitate 191 implementations on any operating system that supports mandatory 192 access controls. 194 LNFS must be designed and developed to facilitate interoperability 195 between different LNFS implementations. 197 LNFS modifications to standard NFSv4.2 implementations must not 198 adversely impact any existing interoperability of those 199 implementations. 201 3.2. Performance & Scalability 203 Security mechanisms often impact on system performance. LNFS should 204 be designed and implemented in a way which avoids significant 205 performance impact where possible. 207 As NFSv4.2 is designed for large-scale distributed networking, LNFS 208 should also be capable of scaling in a similar manner to underlying 209 implementations where possible. 211 LNFS should be respond in a robust manner to system and network 212 outages associated with typical enterprise and Internet environments. 213 At the very least, LNFS should always operate in a fail-safe manner, 214 so that service disruptions do not cause or facilitate security 215 vulnerabilities. 217 3.3. Security Services 219 LNFS should ensure that the following security services are provided 220 for all NFSv4.2 messaging. These services may be provided by lower 221 layers even if NFS has to be aware of and leverage them: 223 o Authentication 225 o Integrity 227 o Privacy 229 Mechanisms and algorithms used in the provision of security services 230 must be configurable, so that appropriate levels of protection may be 231 flexibly specified per mandatory security policy. 233 Strong mutual authentication will be required between the server and 234 the client for Full Mode operation Section 3.5.1. 236 MAC security labels and any related security state must always be 237 protected by these security services when transferred over the 238 network; as must the binding of labels and state to associated 239 objects and subjects. 241 LNFS should support authentication on a context granularity so that 242 different contexts running on a client can use different 243 cryptographic keys and facilities. 245 3.4. Label Encoding, Label Format Specifiers, and Labeling Authorities 247 Encoding of MAC labels and attributes passed over the network must be 248 specified in a complete and unambiguous manner while maintaining the 249 flexibility of MAC implementations. To accomplish this the labels 250 should consist of an opaque component bound with a Label Format 251 Specifier (LFS). The opaque component consists of the label which 252 will be interpreted by the MAC model on the other end while the LFS 253 provides a mechanism for identifying the structure and semantics of 254 the label's components. 256 MAC models base access decisions on security attributes bound to 257 subjects and objects. With a given MAC model, all systems have 258 semantically coherent labeling - a security label must always mean 259 exactly the same thing on every system. While this may not be 260 necessary for simple MAC models it is recommended that most label 261 formats assigned an LFS incorporate this concept into their label 262 format. 264 LNFS must provide a means for servers and clients to identify their 265 LFS for the purposes of authorization, security service selection, 266 and security label interpretation. 268 A negotiation scheme should be provided, allowing systems from 269 different label formats to agree on how they will interpret or 270 translate each others labels. Multiple concurrent agreements may be 271 current between a server and a client. 273 All security labels and related security state transferred across the 274 network must be tagged with a valid LFS. 276 If the LFS of a system changes, it should renegotiate agreements to 277 reflect these changes. 279 If a system receives any security label or security state tagged with 280 an LFS it does not recognize or cannot interpret, it must reject that 281 label or state. 283 NFSv4.2 includes features which may cause a client to cross an LFS 284 boundary when accessing what appears to be a single file system. If 285 LFS negotiation is supported by the client and the server, the server 286 should negotiate a new, concurrent agreement with the client, acting 287 on behalf of the externally located source of the files. 289 LNFS should define an initial negotiation scheme with the primary 290 aims of simplicity and completeness. This is to facilitate practical 291 deployment of systems without being weighed down by complex and over- 292 generalized global schemes. Future extensibility should also be 293 taken into consideration. 295 3.5. Modes of Operation 297 LNFS must cater for two potentially concurrent operating modes, 298 depending on the state of MAC functionality: 300 3.5.1. Full Mode 302 Both the server and the client have MAC functionality enabled, and 303 full LNFS functionality is extended over the network between both 304 client and server. 306 An example of an operation in full mode is as follows. On the 307 initial lookup, the client requests access to an object on the 308 server. It sends its process security context over to the server. 309 The server checks all relevant local policies to determine if that 310 process context from that client is allowed to access the resource. 311 Once this has succeeded the object with its associated security 312 information is released to the client. Once the client receives the 313 object it determines if its local policy allows the process running 314 on the client access to the object. 316 On subsequent operations where the client already has a handle for 317 the file, the order of enforcement is reversed. Since the client 318 already has the security context it may make an access decision 319 against its local policy first. This enables the client to avoid 320 sending requests to the server that it knows will fail regardless of 321 the server's policy. If the client passes the local policy check 322 then it sends the request to the server where the client's process 323 context is used to determine if the server will release that resource 324 to the client. If both checks pass, the client is given the resource 325 and everything succeeds. 327 In the event that the client does not trust the server, it may opt to 328 use an alternate labeling mechanism regardless of the server's 329 ability to return security information. 331 3.5.2. Guest Mode 333 Only one of the server or client has MAC functionality enabled. 335 In the case of the server only having MAC functionality enabled, the 336 server locally enforces its policy, and may selectively provide 337 standard NFS services to clients based on their authentication 338 credentials and/or associated network attributes (e.g. IP address, 339 network interface) according to security policy. The level of trust 340 and access extended to a client in this mode is configuration- 341 specific. 343 In the case of the client only having MAC functionality enabled, the 344 client must operate as a standard NFSv4.2 client, and should 345 selectively provide processes access to servers based upon the 346 security attributes of the local process, and network attributes of 347 the server, according to policy. The client may also override 348 default labeling of the remote file system based upon these security 349 attributes, or other labeling methods such as mount point labeling. 351 In other words, Guest Mode is standard NFSv4.2 over the wire, with 352 the MAC-aware system mapping the MAC-unaware system's processes or 353 objects to security labels based on other characteristics in order to 354 preserve its local MAC guarantees. 356 3.6. Labeling 358 Implementations must validate security labels supplied over the 359 network to ensure that they are within a set of labels permitted from 360 a specific peer, and if not, reject them. Note that a system may 361 permit a different set of labels to be accepted from each peer. 363 3.6.1. Client Labeling 365 At the client, labeling semantics for NFS mounted file systems must 366 remain consistent with those for locally mounted file systems. In 367 particular, user-level labeling operations local to the client must 368 be enacted locally via existing APIs, to ensure compatibility and 369 consistency for applications and libraries. 371 Note that this does not imply any specific mechanism for conveying 372 labels over the network. 374 When an object is newly created by the client, it will calculate the 375 label for the object based on its local policy. Once that is done it 376 will send the request to the server which has the ability to deny the 377 creation of the object with that label based on the server's policy. 378 In creating the file the server must ensure that the label is bound 379 to the object before the object becomes visible to the rest of the 380 system. This ensures that any access control or further labeling 381 decisions are correct for the object. 383 3.6.2. Server Labeling 385 The server must provide the capability for clients to retrieve 386 security labels on all exported file system objects where possible. 387 This includes cases where only in-core and/or read-only security 388 labels are available at the server for any of its exported file 389 systems. 391 The server must honor the ability for a client to specify the label 392 of an object on creation. If the server is MAC enabled it may choose 393 to reject the label specified by the client due to restrictions in 394 the server policy. The server should not attempt to find a suitable 395 label for an object in event of different labeling rules on its end. 396 The server is allowed to translate the label but should not change 397 the semantic meaning of the label. 399 3.7. Policy Enforcement 401 3.7.1. Full Mode 403 The server must enforce its local security policy over all exported 404 objects, for operations which originate both locally and remotely. 406 Requests from authenticated clients must be processed using security 407 labels and credentials supplied by the client as if they originated 408 locally. 410 As with labeling, the system must also take into account any other 411 volatile client security state, such as a change in process security 412 context via dynamic transition. Access decisions should also be made 413 based upon the current client security label accessing the object, 414 rather than the security label which opened it, if different. 416 The client must apply its own policy to remotely located objects, 417 using security labels for the objects obtained from the server. It 418 must be possible to configure the maximum length of time a client may 419 cache state regarding remote labels before re-validating that state 420 with the server. 422 The server must recall delegation of an object if the object's 423 security label changes. 425 A mechanism must exist to allow the client to obtain access, and 426 labeling decisions from the server for locally cached and delegated 427 objects, so that it may apply the server's policy to these objects. 428 If the server's policy changes, the client must flush all object 429 state back to the server. The server must ensure that any flushed 430 state received is consistent with current policy before committing it 431 to stable storage. 433 Any local security state associated with cached or delegated objects 434 must also be flushed back to the server when any other state of the 435 objects is required to be flushed back. 437 3.7.2. Guest Mode 439 If the server is MAC aware and the client is not, the server must not 440 accept security labels provided by the client, and only enforce its 441 local policy to exported objects. In the event that the client is 442 MAC aware while the server is not then the client may deny access or 443 fall back on other methods for providing security labeling. 445 3.8. Namespace Access 447 The server should provide a means to authorize selective access to 448 the exported file system namespace based upon client credentials and 449 according to security policy. 451 This is a common requirement of MLS-enabled systems, which often need 452 to present selective views of namespaces based upon the clearances of 453 the subjects. 455 3.9. Upgrading Existing Server 457 Note that under the MAC model, all objects must have labels. 458 Therefore, if an existing server is upgraded to include LNFS support, 459 then it is the responsibility of the security system to define the 460 behavior for existing objects. For example, if the security system 461 is LFS 0, which means the server just stores and returns labels, then 462 existing files should return labels which are set to an empty value. 464 4. Use Cases 466 MAC labeling is meant to allow NFSv4.2 to be deployed in site 467 configurable security schemes. The LFS and opaque data scheme allows 468 for flexibility to meet these different implementations. In this 469 section, we provide some examples of how NFSv4.2 could be deployed to 470 meet existing needs. This is not an exhaustive listing. 472 4.1. Full MAC labeling support for remotely mounted filesystems 474 In this case, we assume a local networked environment where the 475 servers and clients are under common administrative control. All 476 systems in this network have the same MAC implementation and 477 semantically identical MAC security labels for objects (i.e. labels 478 mean the same thing on different systems, even if the policies on 479 each system may differ to some extent). Clients will be able to 480 apply fine-grained MAC policy to objects accessed via NFS mounts, and 481 thus improve the overall consistency of MAC policy application within 482 this environment. 484 An example of this case would be where user home directories are 485 remotely mounted, and fine-grained MAC policy is implemented to 486 protect, for example, private user data from being read by malicious 487 web scripts running in the user's browser. With Labeled NFS, fine- 488 grained MAC labeling of the user's files will allow the local MAC 489 policy to be implemented and provide the desired protection. 491 4.2. MAC labeling of virtual machine images stored on the network 493 Virtualization is now a commonly implemented feature of modern 494 operating systems, and there is a need to ensure that MAC security 495 policy is able to to protect virtualized resources. A common 496 implementation scheme involves storing virtualized guest filesystems 497 on a networked server, which are then mounted remotely by guests upon 498 instantiation. In this case, there is a need to ensure that the 499 local guest kernel is able to access fine-grained MAC labels on the 500 remotely mounted filesystem so that its MAC security policy can be 501 applied. 503 4.3. International Traffic in Arms Regulations (ITAR) 505 The International Traffic in Arms Regulations (ITAR) is put forth by 506 the United States Department of State, Directorate of Defense and 507 Trade Controls. ITAR places strict requirements on the export and 508 thus access of defense articles and defense services. Organizations 509 that manage projects with articles and services deemed as within the 510 scope of ITAR must ensure the regulations are met. The regulations 511 require an assurance that ITAR information is accessed on a need-to- 512 know basis, thus requiring strict, centrally managed access controls 513 on items labeled as ITAR. Additionally, organizations must be able 514 to prove that the controls were adequately maintained and that 515 foreign nationals were not permitted access to these defense articles 516 or service. ITAR control applicability may be dynamic; information 517 may become subject to ITAR after creation (e.g., when the defense 518 implications of technology are recognized). 520 4.4. Legal Hold/eDiscovery 522 Increased cases of legal holds on electronic sources of information 523 (ESI) have resulted in organizations taking a pro-active approach to 524 reduce the scope and thus costs associated with these activities. 525 ESI Data Maps are increasing in use and require support in operating 526 systems to strictly manage access controls in the case of a legal 527 hold. The sizeable quantity of information involved in a legal 528 discovery request may preclude making a copy of the information to a 529 separate system that manages the legal hold on the copies; this 530 results in a need to enforce the legal hold on the original 531 information. 533 Organizations are taking steps to map out the sources of information 534 that are most likely to be placed under a legal hold, these efforts 535 result in ESI Data Maps. ESI Data Maps specify the Electronic Source 536 of Information and the requirements for sensitivity and criticality. 537 In the case of a legal hold, the ESI data map and labels can be used 538 to ensure the legal hold is properly enforced on the predetermined 539 set of information. An ESI data map narrows the scope of a legal 540 hold to the predetermined ESI. The information must then be 541 protected at a level of security of which the weight and 542 admissibility of that evidence may be proved in a court of law. 543 Current systems use application level controls and do not adequately 544 meet the requirements. Labels may be used in advance when an ESI 545 data map exercise is conducted with controls being applied at the 546 time of a hold or labels may be applied to data sets during an 547 eDiscovery exercise to ensure the data protections are adequate 548 during the legal hold period. 550 Note that this use case requires multi-attribute labels, as both 551 information sensitivity (e.g., to disclosure) and information 552 criticality (e.g., to continued business operations) need to be 553 captured. 555 4.5. Simple security label storage 557 In this case, a mixed and loosely administered network is assumed, 558 where nodes may be running a variety of operating systems with 559 different security mechanisms and security policies. It is desired 560 that network file servers be simply capable of storing and retrieving 561 MAC security labels for clients which use such labels. The Labeled 562 NFS protocol would be implemented here solely to enable transport of 563 MAC security labels across the network. It should be noted that in 564 such an environment, overall security cannot be as strongly enforced 565 as in case (a), and that this scheme is aimed at allowing MAC-capable 566 clients to function with local MAC security policy enabled rather 567 than perhaps disabling it entirely. 569 4.6. Diskless Linux 571 A number of popular operating system distributions depend on a 572 mandatory access control (MAC) model to implement a kernel-enforced 573 security policy. Typically, such models assign particular roles to 574 individual processes, which limit or permit performing certain 575 operations on a set of files, directories, sockets, or other objects. 576 While the enforcing of the policy is typically a matter for the 577 diskless NFS client itself, the filesystem objects in such models 578 will typically carry MAC labels that are used to define policy on 579 access. These policies may, for instance, describe privilege 580 transitions that cannot be replicated using standard NFS ACL based 581 models. 583 For instance on a SYSV compatible system, if the 'init' process 584 spawns a process that attempts to start the 'NetworkManager' 585 executable, there may be a policy that sets up a role transition if 586 the 'init' process and 'NetworkManager' file labels match a 587 particular rule. Without this role transition, the process may find 588 itself having insufficient privileges to perform its primary job of 589 configuring network interfaces. 591 In setups of this type, a lot of the policy targets (such as sockets 592 or privileged system calls) are entirely local to the client. The 593 use of RPCSEC_GSSv3 for enforcing compliance at the server level is 594 therefore of limited value. The ability to permanently label files 595 and have those labels read back by the client is, however, crucial to 596 the ability to enforce that policy. 598 4.7. Multi-Level Security 600 In a MLS system objects are generally assigned a sensitivity level 601 and a set of compartments. The sensitivity levels within the system 602 are given an order ranging from lowest to highest classification 603 level. Read access to an object is allowed when the sensitivity 604 level of the subject "dominates" the object it wants to access. This 605 means that the sensitivity level of the subject is higher than that 606 of the object it wishes to access and that its set of compartments is 607 a super-set of the compartments on the object. 609 The rest of the section will just use sensitivity levels. In general 610 the example is a client that wishes to list the contents of a 611 directory. The system defines the sensitivity levels as Unclassified 612 (U), Secret (S), and Top Secret (TS). The directory to be searched 613 is labeled Top Secret which means access to read the directory will 614 only be granted if the subject making the request is also labeled Top 615 Secret. 617 4.7.1. Full Mode - MAC functional Client and Server 619 In the first part of this example a process on the client is running 620 at the Secret level. The process issues a readdir system call which 621 enters the kernel. Before translating the readdir system call into a 622 request to the NFSv4.2 server the host operating system will consult 623 the MAC module to see if the operation is allowed. Since the process 624 is operating at Secret and the directory to be accessed is labeled 625 Top Secret the MAC module will deny the request and an error code is 626 returned to user space. 628 Consider a second case where instead of running at Secret the process 629 is running at Top Secret. In this case the sensitivity of the 630 process is equal to or greater than that of the directory so the MAC 631 module will allow the request. Now the readdir is translated into 632 the necessary NFSv4.2 call to the server. For the RPC request the 633 client is using the proper credential to assert to the server that 634 the process is running at Top Secret. 636 When the server receives the request it extracts the security label 637 from the RPC session and retrieves the label on the directory. The 638 server then checks with its MAC module if a Top Secret process is 639 allowed to read the contents of the Top Secret directory. Since this 640 is allowed by the policy then the server will return the appropriate 641 information back to the client. 643 In this example the policy on the client and server were both the 644 same. In the event that they were running different policies a 645 translation of the labels might be needed. In this case it could be 646 possible for a check to pass on the client and fail on the server. 647 The server may consider additional information when making its policy 648 decisions. For example the server could determine that a certain 649 subnet is only cleared for data up to Secret classification. If that 650 constraint was in place for the example above the client would still 651 succeed, but the server would fail since the client is asserting a 652 label that it is not able to use (Top Secret on a Secret network). 654 4.7.2. MAC functional Client 656 With a client that is MAC functional and a server which is not, this 657 example is identical to the first part of the previous example. A 658 process on the client labeled Secret wishes to access a Top Secret 659 directory. As in the previous example, this is denied since Secret 660 does not dominate Top Secret. If the process were operating at Top 661 Secret it would pass the local access control check and the NFSv4.2 662 operation would proceed as in a normal NFSv4.2 environment. 664 4.7.3. MAC functional Server 666 With a MAC functional server and a client which is not, the client 667 behaves as if it were in a normal NFSv4.2 environment. Since the 668 process on the client does not provide a security attribute the 669 server must define a mechanism for labeling all requests from a 670 client. Assume that the server is using the same criteria used in 671 the first example. The server sees the request as coming from a 672 subnet that is a Secret network. The server determines that all 673 clients on that subnet will have their requests labeled with Secret. 674 Since the directory on the server is labeled Top Secret and Secret 675 does not dominate Top Secret the server would fail the request with 676 NFS4ERR_ACCESS. 678 5. Security Considerations 680 When either the client or server is operating in guest mode it is 681 important to realize that one side is not enforcing MAC protections. 682 Alternate methods are being used to handle the lack of MAC support 683 and care should be taken to identify and mitigate threats from 684 possible tampering outside of these methods. 686 6. IANA Considerations 688 It is requested that IANA creates a registry of Label Formats to 689 describe the syntactic format and semantics of the security label. 691 7. References 693 7.1. Normative References 695 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 696 Levels", March 1997. 698 [2] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol 699 Specification", RFC 2203, September 1997. 701 [3] Haynes, T. and N. Williams, "Remote Procedure Call (RPC) 702 Security Version 3", draft-williams-rpcsecgssv3 (work in 703 progress), 2011. 705 [4] Quigley, D. and J. Lu, "Registry Specification for MAC Security 706 Label Formats", draft-quigley-label-format-registry (work in 707 progress), 2011. 709 [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 710 Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 712 [6] Eisler, M., "XDR: External Data Representation Standard", 713 RFC 4506, May 2006. 715 [7] Shepler, S., Eisler, M., and D. Noveck, "Network File System 716 (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, 717 January 2010. 719 7.2. Informative References 721 [8] "Section 46.6. Multi-Level Security (MLS) of Deployment Guide: 722 Deployment, configuration and administration of Red Hat 723 Enterprise Linux 5, Edition 6", 2011. 725 [9] Smalley, S., "The Distributed Trusted Operating System (DTOS) 726 Home Page", 727 . 729 [10] Carter, J., "Implementing SELinux Support for NFS", 730 . 732 Appendix A. Acknowledgments 734 David Quigley was the early energy in motivating the entire LNFS 735 effort. 737 James Morris, Jarrett Lu, and Stephen Smalley all were key 738 contributers to both early versions of this document and to many 739 conference calls. 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 Author's Address 760 Thomas Haynes (editor) 761 NetApp 762 9110 E 66th St 763 Tulsa, OK 74133 764 USA 766 Phone: +1 918 307 1415 767 Email: thomas@netapp.com