idnits 2.17.1 draft-ietf-nfsv4-labreqs-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 04, 2013) is 3917 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-41) exists of draft-ietf-nfsv4-minorversion2-19 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFSv4 T. Haynes 3 Internet-Draft NetApp 4 Intended status: Informational August 04, 2013 5 Expires: February 5, 2014 7 Requirements for Labeled NFS 8 draft-ietf-nfsv4-labreqs-04.txt 10 Abstract 12 This memo outlines high-level requirements for the integration of 13 flexible Mandatory Access Control (MAC) functionality into the 14 Network File System (NFS) version 4.2 (NFSv4.2). It describes the 15 level of protections that should be provided over protocol components 16 and the basic structure of the proposed system. The intent here is 17 not to present the protocol changes, but to describe the environment 18 in which they reside. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on February 5, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 57 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.2. Security Services . . . . . . . . . . . . . . . . . . . . 6 60 3.3. Label Encoding, Label Format Specifiers, and Label 61 Checking Authorities . . . . . . . . . . . . . . . . . . . 6 62 3.4. Labeling . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 3.4.1. Client Labeling . . . . . . . . . . . . . . . . . . . 7 64 3.4.2. Server Labeling . . . . . . . . . . . . . . . . . . . 8 65 3.5. Policy Enforcement . . . . . . . . . . . . . . . . . . . . 8 66 3.5.1. Client Enforcement . . . . . . . . . . . . . . . . . . 8 67 3.5.2. Server Enforcement . . . . . . . . . . . . . . . . . . 9 68 3.6. Namespace Access . . . . . . . . . . . . . . . . . . . . . 9 69 3.7. Upgrading Existing Server . . . . . . . . . . . . . . . . 9 70 4. Modes of Operation . . . . . . . . . . . . . . . . . . . . . . 10 71 4.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . . . 10 72 4.2. Limited Server Mode . . . . . . . . . . . . . . . . . . . 11 73 4.3. Guest Mode . . . . . . . . . . . . . . . . . . . . . . . . 11 74 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 5.1. Full MAC labeling support for remotely mounted 76 filesystems . . . . . . . . . . . . . . . . . . . . . . . 12 77 5.2. MAC labeling of virtual machine images stored on the 78 network . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 5.3. International Traffic in Arms Regulations (ITAR) . . . . . 12 80 5.4. Legal Hold/eDiscovery . . . . . . . . . . . . . . . . . . 13 81 5.5. Simple security label storage . . . . . . . . . . . . . . 13 82 5.6. Diskless Linux . . . . . . . . . . . . . . . . . . . . . . 14 83 5.7. Multi-Level Security . . . . . . . . . . . . . . . . . . . 14 84 5.7.1. Full Mode - MAC-functional Client and Server . . . . . 15 85 5.7.2. MAC-Functional Client . . . . . . . . . . . . . . . . 15 86 5.7.3. MAC-Functional Server . . . . . . . . . . . . . . . . 16 87 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 88 6.1. Trust Needed for a Community . . . . . . . . . . . . . . . 16 89 6.2. Guest Modes . . . . . . . . . . . . . . . . . . . . . . . 17 90 6.3. MAC-Functional Client Configuration . . . . . . . . . . . 17 91 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 92 7.1. Normative References . . . . . . . . . . . . . . . . . . . 18 93 7.2. Informative References . . . . . . . . . . . . . . . . . . 18 94 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18 95 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 19 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 98 1. Introduction 100 Mandatory Access Control (MAC) systems have been mainstreamed in 101 modern operating systems such as Linux, FreeBSD, and Solaris. MAC 102 systems bind security attributes to subjects (processes) and objects 103 within a system. These attributes are used with other information in 104 the system to make access control decisions. 106 Access control models such as Unix permissions or Access Control 107 Lists are commonly referred to as Discretionary Access Control (DAC) 108 models. These systems base their access decisions on user identity 109 and resource ownership. In contrast MAC models base their access 110 control decisions on the label on the subject (usually a process) and 111 the object it wishes to access. These labels may contain user 112 identity information but usually contain additional information. In 113 DAC systems users are free to specify the access rules for resources 114 that they own. MAC models base their security decisions on a system 115 wide policy established by an administrator or organization which the 116 users do not have the ability to override. DAC systems offer no real 117 protection against malicious or flawed software due to each program 118 running with the full permissions of the user executing it. 119 Inversely MAC models can confine malicious or flawed software and 120 usually act at a finer granularity than their DAC counterparts. 122 Besides describing the requirements, this document records the 123 functional requirements for the client imposed by the pre-existing 124 security models on the client. This document may help those outside 125 the NFS community understand those issues. 127 2. Definitions 129 Label Format Specifier (LFS): is an identifier used by the client to 130 establish the syntactic format of the security label and the 131 semantic meaning of its components. 133 Label Format Registry: is the IANA registry (see [lfsreg]) 134 containing all registered LFS along with references to the 135 documents that describe the syntactic format and semantics of the 136 security label. 138 Policy Identifier (PI): is an optional part of the definition of a 139 Label Format Specifier which allows for clients and server to 140 identify specific security policies. 142 Object: is a passive resource within the system that we wish to be 143 protected. Objects can be entities such as files, directories, 144 pipes, sockets, and many other system resources relevant to the 145 protection of the system state. 147 Subject: is an active entity, usually a process, which is requesting 148 access to an object. 150 MAC-Aware: is a server which can transmit and store object labels. 152 MAC-Functional: is a client or server which is Labeled NFS enabled. 153 Such a system can interpret labels and apply policies based on the 154 security system. 156 Multi-Level Security (MLS): is a traditional model where objects are 157 given a sensitivity level (Unclassified, Secret, Top Secret, etc) 158 and a category set [RH_MLS]. 160 2.1. Requirements Language 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in [RFC2119]. 166 3. Requirements 168 The following initial requirements have been gathered from users, 169 developers, and from previous development efforts in this area such 170 as DTOS [DTOS] and NSA's experimental NFSv3 enhancements [SENFSV3]. 172 3.1. General 174 A mechanism is required to provide security attribute information to 175 NFSv4 clients and servers. This mechanism has the following 176 requirements: 178 (1) Clients MUST be able to convey to the server the security 179 attribute of the subject making the access request. The server 180 may provide a mechanism to enforce MAC policy based on the 181 requesting subject's security attribute. 183 (2) Servers MUST be able to store and retrieve the security 184 attribute of exported files as requested by the client. 186 (3) Servers MUST provide a mechanism for notifying clients of 187 attribute changes of files on the server. 189 (4) Clients and Servers MUST be able to negotiate Label Formats and 190 provide a mechanism to translate between them as needed. 192 3.2. Security Services 194 Labeled NFS SHOULD support that the following security services are 195 provided for all NFSv4.2 messaging. These services may be provided 196 by lower layers even if NFS has to be aware of and leverage them: 197 o Authentication 198 o Integrity 199 o Privacy 201 Mechanisms and algorithms used in the provision of security services 202 MUST be configurable, so that appropriate levels of protection may be 203 flexibly specified per mandatory security policy. 205 Strong mutual authentication will be required between the server and 206 the client for Full Mode operation Section 4.1. 208 MAC security labels and any related security state SHOULD always be 209 protected by these security services when transferred over the 210 network; as SHOULD the binding of labels and state to associated 211 objects and subjects. 213 Labeled NFS SHOULD support authentication on a context granularity so 214 that different contexts running on a client can use different 215 cryptographic keys and facilities. 217 3.3. Label Encoding, Label Format Specifiers, and Label Checking 218 Authorities 220 Encoding of MAC labels and attributes passed over the network MUST be 221 specified in a complete and unambiguous manner while maintaining the 222 flexibility of MAC implementations. To accomplish this the labels 223 MUST consist of an opaque component bound with a Label Format 224 Specifier (LFS). The LFS component provides a mechanism for 225 identifying the structure and semantics of the opaque component. 226 Meanwhile, the opaque component is the security label which will be 227 interpreted by the MAC models. 229 MAC models base access decisions on security attributes bound to 230 subjects and objects. With a given MAC model, all systems have 231 semantically coherent labeling - a security label MUST always mean 232 exactly the same thing on every system. While this may not be 233 necessary for simple MAC models it is recommended that most label 234 formats assigned an LFS incorporate this concept into their label 235 format. 237 Labeled NFS SHOULD define an initial negotiation scheme with the 238 primary aims of simplicity and completeness. This is to facilitate 239 practical deployment of systems without being weighed down by complex 240 and over-generalized global schemes. Future extensibility SHOULD 241 also be taken into consideration. 243 Labeled NFS MUST provide a means for servers and clients to identify 244 their LFS for the purposes of authorization, security service 245 selection, and security label interpretation. 247 Labeled NFS MUST provide a means for servers and clients to identify 248 their mode of operation (see Section 4). 250 A negotiation scheme SHOULD be provided, allowing systems from 251 different label formats to agree on how they will interpret or 252 translate each others foreign labels. Multiple concurrent agreements 253 may be current between a server and a client. 255 All security labels and related security state transferred across the 256 network MUST be tagged with a valid LFS. 258 If the LFS supported on a system changes, the system SHOULD 259 renegotiate agreements to reflect these changes. 261 If a system receives any security label or security state tagged with 262 an LFS it does not recognize or cannot interpret, it MUST reject that 263 label or state. 265 NFSv4.2 includes features which may cause a client to cross an LFS 266 boundary when accessing what appears to be a single file system. If 267 LFS negotiation is supported by the client and the server, the server 268 SHOULD negotiate a new, concurrent agreement with the client, acting 269 on behalf of the externally located source of the files. 271 3.4. Labeling 273 Implementations MUST validate security labels supplied over the 274 network to ensure that they are within a set of labels permitted from 275 a specific peer, and if not, reject them. Note that a system may 276 permit a different set of labels to be accepted from each peer. 278 3.4.1. Client Labeling 280 At the client, labeling semantics for NFS mounted file systems MUST 281 remain consistent with those for locally mounted file systems. In 282 particular, user-level labeling operations local to the client MUST 283 be enacted locally via existing APIs, to ensure compatibility and 284 consistency for applications and libraries. 286 Note that this does not imply any specific mechanism for conveying 287 labels over the network. 289 When an object is newly created by the client, it will calculate the 290 label for the object based on its policy. Once that is done it will 291 send the request to the server which has the ability to deny the 292 creation of the object with that label based on the server's policy. 293 In creating the file the server MUST ensure that the label is bound 294 to the object before the object becomes visible to the rest of the 295 system. This ensures that any access control or further labeling 296 decisions are correct for the object. 298 3.4.2. Server Labeling 300 The server MUST provide the capability for clients to retrieve 301 security labels on all exported file system objects where possible. 302 This includes cases where only in-core and/or read-only security 303 labels are available at the server for any of its exported file 304 systems. 306 The server MUST honor the ability for a client to specify the label 307 of an object on creation. If the server is MAC enabled it may choose 308 to reject the label specified by the client due to restrictions in 309 the server policy. The server SHOULD NOT attempt to find a suitable 310 label for an object in event of different labeling rules on its end. 311 The server is allowed to translate the label but SHOULD NOT change 312 the semantic meaning of the label. 314 3.5. Policy Enforcement 316 The MAC-Functional client determines if a process request is sent to 317 the remote server. Upon a successful response from the server, it 318 must use its own policies on the object's security labels to 319 determine if the process can be given access. The client SHOULD NOT 320 need to be cognizant if the server is either a Limited Server or 321 fully MAC-Functional. 323 3.5.1. Client Enforcement 325 The client MUST apply its own policy to remotely located objects, 326 using security labels for the objects obtained from the server. It 327 MUST be possible to configure the maximum length of time a client may 328 cache state regarding remote labels before re-validating that state 329 with the server. 331 If the server's policy changes, the client MUST flush all object 332 state back to the server. The server MUST ensure that any flushed 333 state received is consistent with current policy before committing it 334 to stable storage. 336 Any local security state associated with cached or delegated objects 337 MUST also be flushed back to the server when any other state of the 338 objects is required to be flushed back. 340 The implication here is that if the client holds a delegation on an 341 object, then it enforces policy to local changes based on the object 342 label it got from the server. When it tries to commit those changes 343 to the server, it SHOULD be prepared for the server to reject those 344 changes based on the policies of the server. 346 3.5.2. Server Enforcement 348 A MAC-Functional server MUST enforce its security policy over all 349 exported objects, for operations which originate both locally and 350 remotely. 352 Requests from authenticated clients MUST be processed using security 353 labels and credentials supplied by the client as if they originated 354 locally. 356 As with labeling, the system MUST also take into account any other 357 volatile client security state, such as a change in process security 358 context via dynamic transition. Access decisions SHOULD also be made 359 based upon the current client security label accessing the object, 360 rather than the security label which opened it, if different. 362 The server SHOULD recall delegation of an object if the object's 363 security label changes. 365 3.6. Namespace Access 367 The server SHOULD provide a means to authorize selective access to 368 the exported file system namespace based upon client credentials and 369 according to security policy. 371 This is a common requirement of MLS-enabled systems, which often need 372 to present selective views of namespaces based upon the clearances of 373 the subjects. 375 3.7. Upgrading Existing Server 377 Note that under the MAC model, all objects MUST have labels. 378 Therefore, if an existing server is upgraded to include Labeled NFS 379 support, then it is the responsibility of the security system to 380 define the behavior for existing objects. 382 4. Modes of Operation 384 In a Labeled NFS client and server interaction, we can describe three 385 modes of operation: 386 1. Full 387 2. Limited Server 388 3. Guest 389 These modes arise from the level of MAC functionality in the clients 390 and servers. The clients can be non-MAC-Functional and MAC- 391 Functional. The servers can be non-MAC-Functional, MAC-Aware, and 392 MAC-Functional. 394 A MAC-Functional client MUST be able to determine the level of MAC 395 functionality in the server. Likewise, a MAC-Functional server MUST 396 be able to determine whether or not a client is MAC-Functional. As 397 discussed in Section 3.3, the protocol MUST provide for the client 398 and server to make those determinations. 400 4.1. Full Mode 402 The server and the client have mutually recognized MAC functionality 403 enabled, and full Labeled NFS functionality is extended over the 404 network between both client and server. 406 An example of an operation in full mode is as follows. On the 407 initial lookup, the client requests access to an object on the 408 server. It sends its process security context over to the server. 409 The server checks all relevant policies to determine if that process 410 context from that client is allowed to access the resource. Once 411 this has succeeded the object with its associated security 412 information is released to the client. Once the client receives the 413 object it determines if its policies allow the process running on the 414 client access to the object. 416 On subsequent operations where the client already has a handle for 417 the file, the order of enforcement is reversed. Since the client 418 already has the security context it may make an access decision 419 against its policy first. This enables the client to avoid sending 420 requests to the server that it knows will fail regardless of the 421 server's policy. If the client passes its policy checks then it 422 sends the request to the server where the client's process context is 423 used to determine if the server will release that resource to the 424 client. If both checks pass, the client is given the resource and 425 everything succeeds. 427 In the event that the client does not trust the server, it may opt to 428 use an alternate labeling mechanism regardless of the server's 429 ability to return security information. 431 4.2. Limited Server Mode 433 The server is MAC-Aware and the clients are MAC-Functional. The 434 server can store and transmit labels. It cannot enforce labels. The 435 server MUST inform clients when an object label changes for a file 436 the client has open. 438 In this mode, the server may not be aware of the format of any its 439 object labels. Indeed, it may service several different security 440 models at the same time. A client MUST process foreign labels as 441 discussed in Section 3.3. As with the Guest Mode, this mode's level 442 of trust can be degraded if non-MAC-functional clients have access to 443 the server. 445 4.3. Guest Mode 447 Only one of the server or client is MAC-Functional enabled. 449 In the case of the server only being MAC-Functional, the server 450 enforces its policy, and may selectively provide standard NFS 451 services to clients based on their authentication credentials and/or 452 associated network attributes (e.g., IP address, network interface) 453 according to security policy. The level of trust and access extended 454 to a client in this mode is configuration-specific. 456 In the case of the client only being MAC-Functional, the client MUST 457 operate as a standard NFSv4.2 (see [I-D.ietf-nfsv4-minorversion2]) 458 client, and SHOULD selectively provide processes access to servers 459 based upon the security attributes of the local process, and network 460 attributes of the server, according to policy. The client may also 461 override default labeling of the remote file system based upon these 462 security attributes, or other labeling methods such as mount point 463 labeling. 465 In other words, Guest Mode is standard NFSv4.2 over the wire, with 466 the MAC-Functional system mapping the non-MAC-Functional system's 467 processes or objects to security labels based on other 468 characteristics in order to preserve its MAC guarantees. 470 5. Use Cases 472 MAC labeling is meant to allow NFSv4.2 to be deployed in site 473 configurable security schemes. The LFS and opaque data scheme allows 474 for flexibility to meet these different implementations. In this 475 section, we provide some examples of how NFSv4.2 could be deployed to 476 meet existing needs. This is not an exhaustive listing. 478 5.1. Full MAC labeling support for remotely mounted filesystems 480 In this case, we assume a local networked environment where the 481 servers and clients are under common administrative control. All 482 systems in this network have the same MAC implementation and 483 semantically identical MAC security labels for objects (i.e. labels 484 mean the same thing on different systems, even if the policies on 485 each system may differ to some extent). Clients will be able to 486 apply fine-grained MAC policy to objects accessed via NFS mounts, and 487 thus improve the overall consistency of MAC policy application within 488 this environment. 490 An example of this case would be where user home directories are 491 remotely mounted, and fine-grained MAC policy is implemented to 492 protect, for example, private user data from being read by malicious 493 web scripts running in the user's browser. With Labeled NFS, fine- 494 grained MAC labeling of the user's files will allow the MAC policy to 495 be implemented and provide the desired protection. 497 5.2. MAC labeling of virtual machine images stored on the network 499 Virtualization is now a commonly implemented feature of modern 500 operating systems, and there is a need to ensure that MAC security 501 policy is able to protect virtualized resources. A common 502 implementation scheme involves storing virtualized guest filesystems 503 on a networked server, which are then mounted remotely by guests upon 504 instantiation. In this case, there is a need to ensure that the 505 local guest kernel is able to access fine-grained MAC labels on the 506 remotely mounted filesystem so that its MAC security policy can be 507 applied. 509 5.3. International Traffic in Arms Regulations (ITAR) 511 The International Traffic in Arms Regulations (ITAR) is put forth by 512 the United States Department of State, Directorate of Defense and 513 Trade Controls. ITAR places strict requirements on the export and 514 thus access of defense articles and defense services. Organizations 515 that manage projects with articles and services deemed as within the 516 scope of ITAR must ensure the regulations are met. The regulations 517 require an assurance that ITAR information is accessed on a need-to- 518 know basis, thus requiring strict, centrally managed access controls 519 on items labeled as ITAR. Additionally, organizations must be able 520 to prove that the controls were adequately maintained and that 521 foreign nationals were not permitted access to these defense articles 522 or service. ITAR control applicability may be dynamic; information 523 may become subject to ITAR after creation (e.g., when the defense 524 implications of technology are recognized). 526 5.4. Legal Hold/eDiscovery 528 Increased cases of legal holds on electronic sources of information 529 (ESI) have resulted in organizations taking a pro-active approach to 530 reduce the scope and thus costs associated with these activities. 531 ESI Data Maps are increasing in use and require support in operating 532 systems to strictly manage access controls in the case of a legal 533 hold. The sizeable quantity of information involved in a legal 534 discovery request may preclude making a copy of the information to a 535 separate system that manages the legal hold on the copies; this 536 results in a need to enforce the legal hold on the original 537 information. 539 Organizations are taking steps to map out the sources of information 540 that are most likely to be placed under a legal hold, these efforts 541 result in ESI Data Maps. ESI Data Maps specify the Electronic Source 542 of Information and the requirements for sensitivity and criticality. 543 In the case of a legal hold, the ESI data map and labels can be used 544 to ensure the legal hold is properly enforced on the predetermined 545 set of information. An ESI data map narrows the scope of a legal 546 hold to the predetermined ESI. The information must then be 547 protected at a level of security of which the weight and 548 admissibility of that evidence may be proved in a court of law. 549 Current systems use application level controls and do not adequately 550 meet the requirements. Labels may be used in advance when an ESI 551 data map exercise is conducted with controls being applied at the 552 time of a hold or labels may be applied to data sets during an 553 eDiscovery exercise to ensure the data protections are adequate 554 during the legal hold period. 556 Note that this use case requires multi-attribute labels, as both 557 information sensitivity (e.g., to disclosure) and information 558 criticality (e.g., to continued business operations) need to be 559 captured. 561 5.5. Simple security label storage 563 In this case, a mixed and loosely administered network is assumed, 564 where nodes may be running a variety of operating systems with 565 different security mechanisms and security policies. It is desired 566 that network file servers be simply capable of storing and retrieving 567 MAC security labels for clients which use such labels. The Labeled 568 NFS protocol would be implemented here solely to enable transport of 569 MAC security labels across the network. It should be noted that in 570 such an environment, overall security cannot be as strongly enforced 571 as when the server is also enforcing, and that this scheme is aimed 572 at allowing MAC-capable clients to function with its MAC security 573 policy enabled rather than perhaps disabling it entirely. 575 5.6. Diskless Linux 577 A number of popular operating system distributions depend on a 578 mandatory access control (MAC) model to implement a kernel-enforced 579 security policy. Typically, such models assign particular roles to 580 individual processes, which limit or permit performing certain 581 operations on a set of files, directories, sockets, or other objects. 582 While the enforcing of the policy is typically a matter for the 583 diskless NFS client itself, the filesystem objects in such models 584 will typically carry MAC labels that are used to define policy on 585 access. These policies may, for instance, describe privilege 586 transitions that cannot be replicated using standard NFS ACL based 587 models. 589 For instance on a SYSV compatible system, if the 'init' process 590 spawns a process that attempts to start the 'NetworkManager' 591 executable, there may be a policy that sets up a role transition if 592 the 'init' process and 'NetworkManager' file labels match a 593 particular rule. Without this role transition, the process may find 594 itself having insufficient privileges to perform its primary job of 595 configuring network interfaces. 597 In setups of this type, a lot of the policy targets (such as sockets 598 or privileged system calls) are entirely local to the client. The 599 use of RPCSEC_GSSv3 ([rpcsecgssv3]) for enforcing compliance at the 600 server level is therefore of limited value. The ability to 601 permanently label files and have those labels read back by the client 602 is, however, crucial to the ability to enforce that policy. 604 5.7. Multi-Level Security 606 In a MLS system objects are generally assigned a sensitivity level 607 and a set of compartments. The sensitivity levels within the system 608 are given an order ranging from lowest to highest classification 609 level. Read access to an object is allowed when the sensitivity 610 level of the subject "dominates" the object it wants to access. This 611 means that the sensitivity level of the subject is higher than that 612 of the object it wishes to access and that its set of compartments is 613 a super-set of the compartments on the object. 615 The rest of the section will just use sensitivity levels. In general 616 the example is a client that wishes to list the contents of a 617 directory. The system defines the sensitivity levels as Unclassified 618 (U), Secret (S), and Top Secret (TS). The directory to be searched 619 is labeled Top Secret which means access to read the directory will 620 only be granted if the subject making the request is also labeled Top 621 Secret. 623 5.7.1. Full Mode - MAC-functional Client and Server 625 In the first part of this example a process on the client is running 626 at the Secret level. The process issues a readdir() system call 627 which enters the kernel. Before translating the readdir() system 628 call into a request to the NFSv4.2 server the host operating system 629 will consult the MAC module to see if the operation is allowed. 630 Since the process is operating at Secret and the directory to be 631 accessed is labeled Top Secret the MAC module will deny the request 632 and an error code is returned to user space. 634 Consider a second case where instead of running at Secret the process 635 is running at Top Secret. In this case the sensitivity of the 636 process is equal to or greater than that of the directory so the MAC 637 module will allow the request. Now the readdir() is translated into 638 the necessary NFSv4.2 call to the server. For the RPC request the 639 client is using the proper credential to assert to the server that 640 the process is running at Top Secret. 642 When the server receives the request it extracts the security label 643 from the RPC session and retrieves the label on the directory. The 644 server then checks with its MAC module if a Top Secret process is 645 allowed to read the contents of the Top Secret directory. Since this 646 is allowed by the policy then the server will return the appropriate 647 information back to the client. 649 In this example the policy on the client and server were both the 650 same. In the event that they were running different policies a 651 translation of the labels might be needed. In this case it could be 652 possible for a check to pass on the client and fail on the server. 653 The server may consider additional information when making its policy 654 decisions. For example the server could determine that a certain 655 subnet is only cleared for data up to Secret classification. If that 656 constraint was in place for the example above the client would still 657 succeed, but the server would fail since the client is asserting a 658 label that it is not able to use (Top Secret on a Secret network). 660 5.7.2. MAC-Functional Client 662 In these scenarios, the server is either non-MAC-Aware or MAC-Aware. 663 The actions of the client will depend whether it is configured to 664 treat the MAC-Aware server in the same manner as the non-MAC-Aware 665 one. I.e., does it utilize the approach presented in Section 4.3 or 666 does it allow the MAC-Aware server to return labels? 668 With a client that is MAC-Functional and using the example in the 669 previous section, the result should be the same. The one difference 670 is that all decisions are made on the client. 672 5.7.2.1. MAC-Aware Server 674 A process on the client labeled Secret wishes to access a directory 675 labeled Top Secret on the server. This is denied since Secret does 676 not dominate Top Secret. Note that there will be NFSv4.2 operations 677 issued that return an object label for the client to process. 679 Note that in this scenario, all of the clients must be MAC- 680 Functional. A single client which does not do its access control 681 checks would violate the model. 683 5.7.2.2. Non-MAC-Aware Server 685 A process on the client labeled Secret wishes to access a directory 686 which the client's policies label as Top Secret on the server. This 687 is denied since Secret does not dominate Top Secret. Note that there 688 will not be NFSv4.2 operations issued. If the process had instead a 689 Top Secret process label, the client would issue NFSv4.2 operations 690 to access the directory on the server. 692 5.7.3. MAC-Functional Server 694 With a MAC-Functional server and a client which is not, the client 695 behaves as if it were in a normal NFSv4.2 environment. Since the 696 process on the client does not provide a security attribute the 697 server must define a mechanism for labeling all requests from a 698 client. Assume that the server is using the same criteria used in 699 the first example. The server sees the request as coming from a 700 subnet that is a Secret network. The server determines that all 701 clients on that subnet will have their requests labeled with Secret. 702 Since the directory on the server is labeled Top Secret and Secret 703 does not dominate Top Secret the server would fail the request with 704 NFS4ERR_ACCESS. 706 6. Security Considerations 708 6.1. Trust Needed for a Community 710 Labeled NFS is a transport mechanism for labels, a storage 711 requirement for labels, and a definition of how to interpret labels. 712 It defines the responsibilities of the client and the server in the 713 various permutations of being MAC-Functional. It does not however 714 dictate in any manner whether assumptions can be made about other 715 entities in the relationship. For example, it does not define 716 whether a MAC-Functional client can demand that a MAC-Aware server 717 only accept requests from other MAC-Functional clients. That is a 718 policy based in a MAC model and this document does not impose 719 policies on systems. 721 As the requirement is a policy, it can be met with the use of a MAC 722 model. Let L be a LFS which implements the Limited Server mode, 723 i.e., a MAC-Aware server connected to MAC-Functional clients. Then a 724 new LFS L' can be created which has the additional policy that the 725 MAC-Aware server MUST NOT accept any requests from a non-MAC- 726 Functional client. 728 6.2. Guest Modes 730 When either the client or server is operating in guest mode it is 731 important to realize that one side is not enforcing MAC protections. 732 Alternate methods are being used to handle the lack of MAC support 733 and care should be taken to identify and mitigate threats from 734 possible tampering outside of these methods. 736 6.3. MAC-Functional Client Configuration 738 We defined a MAC model as a access control decision made on a system 739 which normal users do not have the ability to override policies (see 740 Section 1). If the process labels are created solely on the client, 741 then if a malicious user has sufficient access on that client, the 742 Labeled NFS model is compromised. Note that this is no different 743 from: 745 o current implementations in which the server uses policies to 746 effectively determine the object label for requests from the 747 client, or 749 o local decisions made on the client by the MAC security system. 751 The server must either explicitly trust the client (as in [SENFSV3]) 752 or the MAC model should enforce that users cannot override policies, 753 perhaps via a externally managed source. 755 Once the labels leave the client, they can be protected by the 756 transport mechanism as described in Section 3.2. 758 7. References 759 7.1. Normative References 761 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 762 Requirement Levels", March 1997. 764 7.2. Informative References 766 [DTOS] Smalley, S., "The Distributed Trusted Operating System 767 (DTOS) Home Page", . 770 [I-D.ietf-nfsv4-minorversion2] 771 Haynes, T. and D. Noveck, "NFS Version 4 Minor Version 2", 772 draft-ietf-nfsv4-minorversion2-19 (Work In Progress), 773 March 2013. 775 [RH_MLS] "Section 46.6. Multi-Level Security (MLS) of Deployment 776 Guide: Deployment, configuration and administration of Red 777 Hat Enterprise Linux 5, Edition 6", 2011. 779 [SENFSV3] Carter, J., "Implementing SELinux Support for NFS", . 782 [lfsreg] Quigley, D. and J. Lu, "Registry Specification for MAC 783 Security Label Formats", 784 draft-quigley-label-format-registry (work in progress), 785 2011. 787 [rpcsecgssv3] 788 Haynes, T. and N. Williams, "Remote Procedure Call (RPC) 789 Security Version 3", draft-williams-rpcsecgssv3 (work in 790 progress), 2011. 792 Appendix A. Acknowledgments 794 David Quigley was the early energy in motivating the entire Labeled 795 NFS effort. 797 James Morris, Jarrett Lu, and Stephen Smalley all were key 798 contributors to both early versions of this document and to many 799 conference calls. 801 Kathleen Moriarty provided the use cases for ITAR and Legal Hold/ 802 eDiscovery. 804 Dan Walsh provided use cases for Secure Virtualization, Sandboxing, 805 and NFS homedir labeling to handle process separation. 807 Trond Myklebust provided use cases for secure diskless NFS clients. 809 Both Nico Williams and Bryce Nordgren challenged assumptions during 810 the review processes. 812 Appendix B. RFC Editor Notes 814 [RFC Editor: please remove this section prior to publishing this 815 document as an RFC] 817 [RFC Editor: prior to publishing this document as an RFC, please 818 replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the 819 RFC number of this document] 821 Author's Address 823 Thomas Haynes 824 NetApp 825 495 E Java Dr 826 Sunnyvale, CA 95054 827 USA 829 Phone: +1 408 419 3018 830 Email: thomas@netapp.com