idnits 2.17.1 draft-ietf-nfsv4-labreqs-05.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 date (December 02, 2013) is 3795 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-21 Summary: 0 errors (**), 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 December 02, 2013 5 Expires: June 05, 2014 7 Requirements for Labeled NFS 8 draft-ietf-nfsv4-labreqs-05.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 June 05, 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 57 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.2. Security Services . . . . . . . . . . . . . . . . . . . . 5 60 3.3. Label Encoding, Label Format Specifiers, and Label 61 Checking Authorities . . . . . . . . . . . . . . . . . . 5 62 3.4. Labeling . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.4.1. Client Labeling . . . . . . . . . . . . . . . . . . . 6 64 3.4.2. Server Labeling . . . . . . . . . . . . . . . . . . . 7 65 3.5. Policy Enforcement . . . . . . . . . . . . . . . . . . . 7 66 3.5.1. Client Enforcement . . . . . . . . . . . . . . . . . 7 67 3.5.2. Server Enforcement . . . . . . . . . . . . . . . . . 8 68 3.6. Namespace Access . . . . . . . . . . . . . . . . . . . . 8 69 3.7. Upgrading Existing Server . . . . . . . . . . . . . . . . 8 70 4. Modes of Operation . . . . . . . . . . . . . . . . . . . . . 9 71 4.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . . . 9 72 4.2. Limited Server Mode . . . . . . . . . . . . . . . . . . . 10 73 4.3. Guest Mode . . . . . . . . . . . . . . . . . . . . . . . 10 74 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 5.1. Full MAC labeling support for remotely mounted 76 filesystems . . . . . . . . . . . . . . . . . . . . . . . 11 77 5.2. MAC labeling of virtual machine images stored on the 78 network . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 5.3. Simple security label storage . . . . . . . . . . . . . . 11 80 5.4. Diskless Linux . . . . . . . . . . . . . . . . . . . . . 12 81 5.5. Multi-Level Security . . . . . . . . . . . . . . . . . . 12 82 5.5.1. Full Mode - MAC-functional Client and Server . . . . 13 83 5.5.2. MAC-Functional Client . . . . . . . . . . . . . . . . 14 84 5.5.3. MAC-Functional Server . . . . . . . . . . . . . . . . 14 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 87 7.1. Trust Needed for a Community . . . . . . . . . . . . . . 15 88 7.2. Guest Modes . . . . . . . . . . . . . . . . . . . . . . . 15 89 7.3. MAC-Functional Client Configuration . . . . . . . . . . . 15 90 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 91 8.1. Normative References . . . . . . . . . . . . . . . . . . 16 92 8.2. Informative References . . . . . . . . . . . . . . . . . 16 93 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 17 94 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 17 95 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 97 1. Introduction 99 Mandatory Access Control (MAC) ([RFC4949]) systems have been 100 mainstreamed in modern operating systems such as Linux, FreeBSD, and 101 Solaris. MAC systems bind security attributes to subjects 102 (processes) and objects within a system. These attributes are used 103 with other information in the system to make access control 104 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 offers some 117 protection against unauthorized users running malicious software. 118 However, even an authorized user can execute malicious or flawed 119 software with those programs running with the full permissions of the 120 user executing it. Inversely MAC models can confine malicious or 121 flawed software and usually act at a finer granularity than their DAC 122 counterparts. 124 Besides describing the requirements, this document records the 125 functional requirements for the client imposed by the pre-existing 126 security models on the client. This document may help those outside 127 the NFS community understand those issues. 129 2. Definitions 131 Foreign Label: is when a MAC implementation encounters a label in a 132 format other than it uses for encoding. 134 Label Format Specifier (LFS): is an identifier used by the client to 135 establish the syntactic format of the security label and the 136 semantic meaning of its components. 138 Label Format Registry: is the IANA registry (see [lfsreg]) 139 containing all registered LFS along with references to the 140 documents that describe the syntactic format and semantics of the 141 security label. 143 MAC-Aware: is a server which can transmit and store object labels. 145 MAC-Functional: is a client or server which is Labeled NFS enabled. 146 Such a system can interpret labels and apply policies based on the 147 security system. 149 Multi-Level Security (MLS): is a traditional model where objects are 150 given a sensitivity level (Unclassified, Secret, Top Secret, etc) 151 and a category set [RH_MLS]. 153 Object: is a passive resource within the system that we wish to be 154 protected. Objects can be entities such as files, directories, 155 pipes, sockets, and many other system resources relevant to the 156 protection of the system state. 158 Policy Identifier (PI): is an optional part of the definition of a 159 Label Format Specifier which allows for clients and server to 160 identify specific security policies. 162 Subject: is an active entity, usually a process, which is requesting 163 access to an object. 165 2.1. Requirements Language 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in [RFC2119]. 171 3. Requirements 173 The following initial requirements have been gathered from users, 174 developers, and from previous development efforts in this area such 175 as DTOS [DTOS] and NSA's experimental NFSv3 enhancements [SENFSV3]. 177 3.1. General 179 A mechanism is required to provide security attribute information to 180 NFSv4 clients and servers. This mechanism has the following 181 requirements: 183 (1) Clients MUST be able to convey to the server the client's 184 priveleges, i.e., the subject, for making the access request. The 185 server may provide a mechanism to enforce MAC policy based on the 186 requesting client's priveleges. 188 (2) Servers MUST be able to store and retrieve the security 189 attribute of exported files as requested by the client. 191 (3) Servers MUST provide a mechanism for notifying clients of 192 attribute changes of files on the server. 194 (4) Clients and Servers MUST be able to negotiate Label Formats and 195 provide a mechanism to translate between them as needed. 197 3.2. Security Services 199 Labeled NFS or the underlying system on which the Labeled NFS 200 operates MUST provide the following security services for all NFSv4.2 201 messaging 203 o Authentication 204 o Integrity 205 o Privacy 207 Mechanisms and algorithms used in the provision of security services 208 MUST be configurable, so that appropriate levels of protection may be 209 flexibly specified per mandatory security policy. 211 Strong mutual authentication is required between the server and the 212 client for Full Mode operation Section 4.1. 214 MAC security labels and any related security state MUST always be 215 protected by these security services when transferred over the 216 network; as MUST the binding of labels and state to associated 217 objects and subjects. 219 Labeled NFS SHOULD support authentication on a context granularity so 220 that different contexts running on a client can use different 221 cryptographic keys and facilities. 223 3.3. Label Encoding, Label Format Specifiers, and Label Checking 224 Authorities 226 Encoding of MAC labels and attributes passed over the network MUST be 227 specified in a complete and unambiguous manner while maintaining the 228 flexibility of MAC implementations. To accomplish this the labels 229 MUST consist of a format-specific component bound with a Label Format 230 Specifier (LFS). The LFS component provides a mechanism for 231 identifying the structure and semantics of the opaque component. 232 Meanwhile, the opaque component is the security label which will be 233 interpreted by the MAC models. 235 MAC models base access decisions on security attributes priveleges 236 bound to subjects and objects, respectively. With a given MAC model, 237 all systems have semantically coherent labeling - a security label 238 MUST always mean exactly the same thing on every system. While this 239 may not be necessary for simple MAC models it is recommended that 240 most label formats assigned an LFS incorporate semantically coherent 241 labeling into their label format. 243 Labeled NFS SHOULD define an initial negotiation scheme with the 244 primary aims of simplicity and completeness. This is to facilitate 245 practical deployment of systems without being weighed down by complex 246 and over-generalized global schemes. Future extensibility SHOULD 247 also be taken into consideration. 249 Labeled NFS MUST provide a means for servers and clients to identify 250 their LFS for the purposes of authorization, security service 251 selection, and security label interpretation. 253 Labeled NFS MUST provide a means for servers and clients to identify 254 their mode of operation (see Section 4). 256 A negotiation scheme SHOULD be provided, allowing systems from 257 different label formats to agree on how they will interpret or 258 translate each others foreign labels. Multiple concurrent agreements 259 may be current between a server and a client. 261 All security labels and related security state transferred across the 262 network MUST be tagged with a valid LFS. 264 If the LFS supported on a system changes, the system SHOULD 265 renegotiate agreements to reflect these changes. 267 If a system receives any security label or security state tagged with 268 an LFS it does not recognize or cannot interpret, it MUST reject that 269 label or state. 271 NFSv4.2 includes features which may cause a client to cross an LFS 272 boundary when accessing what appears to be a single file system. If 273 LFS negotiation is supported by the client and the server, the server 274 SHOULD negotiate a new, concurrent agreement with the client, acting 275 on behalf of the externally located source of the files. 277 3.4. Labeling 279 Implementations MUST validate security labels supplied over the 280 network to ensure that they are within a set of labels permitted from 281 a specific peer, and if not, reject them. Note that a system may 282 permit a different set of labels to be accepted from each peer. 284 3.4.1. Client Labeling 286 At the client, labeling semantics for NFS mounted file systems MUST 287 remain consistent with those for locally mounted file systems. In 288 particular, user-level labeling operations local to the client MUST 289 be enacted locally via existing APIs, to ensure compatibility and 290 consistency for applications and libraries. 292 Note that this does not imply any specific mechanism for conveying 293 labels over the network. 295 When an object is newly created by the client, it will calculate the 296 label for the object based on its policy. Once that is done it will 297 send the request to the server which has the ability to deny the 298 creation of the object with that label based on the server's policy. 299 In creating the file the server MUST ensure that the label is bound 300 to the object before the object becomes visible to the rest of the 301 system. This ensures that any access control or further labeling 302 decisions are correct for the object. 304 3.4.2. Server Labeling 306 The server MUST provide the capability for clients to retrieve 307 security labels on all exported file system objects where possible. 308 This includes cases where only in-core and/or read-only security 309 labels are available at the server for any of its exported file 310 systems. 312 The server MUST honor the ability for a client to specify the label 313 of an object on creation. If the server is MAC enabled it may choose 314 to reject the label specified by the client due to restrictions in 315 the server policy. The server SHOULD NOT attempt to find a suitable 316 label for an object in event of different labeling rules on its end. 317 The server is allowed to translate the label but MUST NOT change the 318 semantic meaning of the label. 320 3.5. Policy Enforcement 322 The MAC-Functional client determines if a process request is sent to 323 the remote server. Upon a successful response from the server, it 324 must use its own policies on the object's security labels to 325 determine if the process can be given access. The client SHOULD NOT 326 need to be cognizant if the server is either a Limited Server or 327 fully MAC-Functional. 329 3.5.1. Client Enforcement 331 The client MUST apply its own policy to remotely located objects, 332 using security labels for the objects obtained from the server. It 333 MUST be possible to configure the maximum length of time a client may 334 cache state regarding remote labels before re-validating that state 335 with the server. 337 If the server's policy changes, the client MUST flush all object 338 state back to the server. The server MUST ensure that any flushed 339 state received is consistent with current policy before committing it 340 to stable storage. 342 Any local security state associated with cached or delegated objects 343 MUST also be flushed back to the server when any other state of the 344 objects is required to be flushed back. 346 The implication here is that if the client holds a delegation on an 347 object, then it enforces policy to local changes based on the object 348 label it got from the server. When it tries to commit those changes 349 to the server, it SHOULD be prepared for the server to reject those 350 changes based on the policies of the server. 352 3.5.2. Server Enforcement 354 A MAC-Functional server MUST enforce its security policy over all 355 exported objects, for operations which originate both locally and 356 remotely. 358 Requests from authenticated clients MUST be processed using security 359 labels and credentials supplied by the client as if they originated 360 locally. 362 As with labeling, the system MUST also take into account any other 363 volatile client security state, such as a change in process security 364 context via dynamic transition. Access decisions SHOULD also be made 365 based upon the current client security label accessing the object, 366 rather than the security label which opened it, if different. 368 The server SHOULD recall delegation of an object if the object's 369 security label changes. 371 3.6. Namespace Access 373 The server SHOULD provide a means to authorize selective access to 374 the exported file system namespace based upon client credentials and 375 according to security policy. 377 This is a common requirement of MLS-enabled systems, which often need 378 to present selective views of namespaces based upon the clearances of 379 the subjects. 381 3.7. Upgrading Existing Server 383 Note that under the MAC model, all objects MUST have labels. 384 Therefore, if an existing server is upgraded to include Labeled NFS 385 support, then it is the responsibility of the security system to 386 define the behavior for existing objects. 388 4. Modes of Operation 390 In a Labeled NFS client and server interaction, we can describe three 391 modes of operation: 393 1. Full 394 2. Limited Server 395 3. Guest 397 These modes arise from the level of MAC functionality in the clients 398 and servers. The clients can be non-MAC-Functional and MAC- 399 Functional. The servers can be non-MAC-Functional, MAC-Aware, and 400 MAC-Functional. 402 A MAC-Functional client MUST be able to determine the level of MAC 403 functionality in the server. Likewise, a MAC-Functional server MUST 404 be able to determine whether or not a client is MAC-Functional. As 405 discussed in Section 3.3, the protocol MUST provide for the client 406 and server to make those determinations. 408 4.1. Full Mode 410 The server and the client have mutually recognized MAC functionality 411 enabled, and full Labeled NFS functionality is extended over the 412 network between both client and server. 414 An example of an operation in full mode is as follows. On the 415 initial lookup, the client requests access to an object on the 416 server. It sends its process security context over to the server. 417 The server checks all relevant policies to determine if that process 418 context from that client is allowed to access the resource. Once 419 this has succeeded the object with its associated security 420 information is released to the client. Once the client receives the 421 object it determines if its policies allow the process running on the 422 client access to the object. 424 On subsequent operations where the client already has a handle for 425 the file, the order of enforcement is reversed. Since the client 426 already has the security context it may make an access decision 427 against its policy first. This enables the client to avoid sending 428 requests to the server that it knows will fail regardless of the 429 server's policy. If the client passes its policy checks then it 430 sends the request to the server where the client's process context is 431 used to determine if the server will release that resource to the 432 client. If both checks pass, the client is given the resource and 433 everything succeeds. 435 In the event that the client does not trust the server, it may opt to 436 use an alternate labeling mechanism regardless of the server's 437 ability to return security information. 439 4.2. Limited Server Mode 441 The server is MAC-Aware and the clients are MAC-Functional. The 442 server can store and transmit labels. It cannot enforce labels. The 443 server MUST inform clients when an object label changes for a file 444 the client has open. 446 In this mode, the server may not be aware of the format of any its 447 object labels. Indeed, it may service several different security 448 models at the same time. A client MUST process foreign labels as 449 discussed in Section 3.3. As with the Guest Mode, this mode's level 450 of trust can be degraded if non-MAC-functional clients have access to 451 the server. 453 4.3. Guest Mode 455 Only one of the server or client is MAC-Functional enabled. 457 In the case of the server only being MAC-Functional, the server 458 enforces its policy, and may selectively provide standard NFS 459 services to clients based on their authentication credentials and/or 460 associated network attributes (e.g., IP address, network interface) 461 according to security policy. The level of trust and access extended 462 to a client in this mode is configuration-specific. 464 In the case of the client only being MAC-Functional, the client MUST 465 operate as a standard NFSv4.2 (see [I-D.ietf-nfsv4-minorversion2]) 466 client, and SHOULD selectively provide processes access to servers 467 based upon the security attributes of the local process, and network 468 attributes of the server, according to policy. The client may also 469 override default labeling of the remote file system based upon these 470 security attributes, or other labeling methods such as mount point 471 labeling. 473 In other words, Guest Mode is standard NFSv4.2 over the wire, with 474 the MAC-Functional system mapping the non-MAC-Functional system's 475 processes or objects to security labels based on other 476 characteristics in order to preserve its MAC guarantees. 478 5. Use Cases 480 MAC labeling is meant to allow NFSv4.2 to be deployed in site 481 configurable security schemes. The LFS and opaque data scheme allows 482 for flexibility to meet these different implementations. In this 483 section, we provide some examples of how NFSv4.2 could be deployed to 484 meet existing needs. This is not an exhaustive listing. 486 5.1. Full MAC labeling support for remotely mounted filesystems 488 In this case, we assume a local networked environment where the 489 servers and clients are under common administrative control. All 490 systems in this network have the same MAC implementation and 491 semantically identical MAC security labels for objects (i.e. labels 492 mean the same thing on different systems, even if the policies on 493 each system may differ to some extent). Clients will be able to 494 apply fine-grained MAC policy to objects accessed via NFS mounts, and 495 thus improve the overall consistency of MAC policy application within 496 this environment. 498 An example of this case would be where user home directories are 499 remotely mounted, and fine-grained MAC policy is implemented to 500 protect, for example, private user data from being read by malicious 501 web scripts running in the user's browser. With Labeled NFS, fine- 502 grained MAC labeling of the user's files will allow the MAC policy to 503 be implemented and provide the desired protection. 505 5.2. MAC labeling of virtual machine images stored on the network 507 Virtualization is now a commonly implemented feature of modern 508 operating systems, and there is a need to ensure that MAC security 509 policy is able to protect virtualized resources. A common 510 implementation scheme involves storing virtualized guest filesystems 511 on a networked server, which are then mounted remotely by guests upon 512 instantiation. In this case, there is a need to ensure that the 513 local guest kernel is able to access fine-grained MAC labels on the 514 remotely mounted filesystem so that its MAC security policy can be 515 applied. 517 5.3. Simple security label storage 519 In this case, a mixed and loosely administered network is assumed, 520 where nodes may be running a variety of operating systems with 521 different security mechanisms and security policies. It is desired 522 that network file servers be simply capable of storing and retrieving 523 MAC security labels for clients which use such labels. The Labeled 524 NFS protocol would be implemented here solely to enable transport of 525 MAC security labels across the network. It should be noted that in 526 such an environment, overall security cannot be as strongly enforced 527 as when the server is also enforcing, and that this scheme is aimed 528 at allowing MAC-capable clients to function with its MAC security 529 policy enabled rather than perhaps disabling it entirely. 531 5.4. Diskless Linux 533 A number of popular operating system distributions depend on a 534 mandatory access control (MAC) model to implement a kernel-enforced 535 security policy. Typically, such models assign particular roles to 536 individual processes, which limit or permit performing certain 537 operations on a set of files, directories, sockets, or other objects. 538 While the enforcing of the policy is typically a matter for the 539 diskless NFS client itself, the filesystem objects in such models 540 will typically carry MAC labels that are used to define policy on 541 access. These policies may, for instance, describe privilege 542 transitions that cannot be replicated using standard NFS ACL based 543 models. 545 For instance on a SYSV compatible system, if the 'init' process 546 spawns a process that attempts to start the 'NetworkManager' 547 executable, there may be a policy that sets up a role transition if 548 the 'init' process and 'NetworkManager' file labels match a 549 particular rule. Without this role transition, the process may find 550 itself having insufficient privileges to perform its primary job of 551 configuring network interfaces. 553 In setups of this type, a lot of the policy targets (such as sockets 554 or privileged system calls) are entirely local to the client. The 555 use of RPCSEC_GSSv3 ([rpcsecgssv3]) for enforcing compliance at the 556 server level is therefore of limited value. The ability to 557 permanently label files and have those labels read back by the client 558 is, however, crucial to the ability to enforce that policy. 560 5.5. Multi-Level Security 561 In a MLS system objects are generally assigned a sensitivity level 562 and a set of compartments. The sensitivity levels within the system 563 are given an order ranging from lowest to highest classification 564 level. Read access to an object is allowed when the sensitivity 565 level of the subject "dominates" the object it wants to access. This 566 means that the sensitivity level of the subject is higher than that 567 of the object it wishes to access and that its set of compartments is 568 a super-set of the compartments on the object. 570 The rest of the section will just use sensitivity levels. In general 571 the example is a client that wishes to list the contents of a 572 directory. The system defines the sensitivity levels as Unclassified 573 (U), Secret (S), and Top Secret (TS). The directory to be searched 574 is labeled Top Secret which means access to read the directory will 575 only be granted if the subject making the request is also labeled Top 576 Secret. 578 5.5.1. Full Mode - MAC-functional Client and Server 580 In the first part of this example a process on the client is running 581 at the Secret level. The process issues a readdir() system call 582 which enters the kernel. Before translating the readdir() system 583 call into a request to the NFSv4.2 server the host operating system 584 will consult the MAC module to see if the operation is allowed. 585 Since the process is operating at Secret and the directory to be 586 accessed is labeled Top Secret the MAC module will deny the request 587 and an error code is returned to user space. 589 Consider a second case where instead of running at Secret the process 590 is running at Top Secret. In this case the sensitivity of the 591 process is equal to or greater than that of the directory so the MAC 592 module will allow the request. Now the readdir() is translated into 593 the necessary NFSv4.2 call to the server. For the RPC request the 594 client is using the proper credential to assert to the server that 595 the process is running at Top Secret. 597 When the server receives the request it extracts the security label 598 from the RPC session and retrieves the label on the directory. The 599 server then checks with its MAC module if a Top Secret process is 600 allowed to read the contents of the Top Secret directory. Since this 601 is allowed by the policy then the server will return the appropriate 602 information back to the client. 604 In this example the policy on the client and server were both the 605 same. In the event that they were running different policies a 606 translation of the labels might be needed. In this case it could be 607 possible for a check to pass on the client and fail on the server. 608 The server may consider additional information when making its policy 609 decisions. For example the server could determine that a certain 610 subnet is only cleared for data up to Secret classification. If that 611 constraint was in place for the example above the client would still 612 succeed, but the server would fail since the client is asserting a 613 label that it is not able to use (Top Secret on a Secret network). 615 5.5.2. MAC-Functional Client 617 In these scenarios, the server is either non-MAC-Aware or MAC-Aware. 618 The actions of the client will depend whether it is configured to 619 treat the MAC-Aware server in the same manner as the non-MAC-Aware 620 one. I.e., does it utilize the approach presented in Section 4.3 or 621 does it allow the MAC-Aware server to return labels? 623 With a client that is MAC-Functional and using the example in the 624 previous section, the result should be the same. The one difference 625 is that all decisions are made on the client. 627 5.5.2.1. MAC-Aware Server 629 A process on the client labeled Secret wishes to access a directory 630 labeled Top Secret on the server. This is denied since Secret does 631 not dominate Top Secret. Note that there will be NFSv4.2 operations 632 issued that return an object label for the client to process. 634 Note that in this scenario, all of the clients must be MAC- 635 Functional. A single client which does not do its access control 636 checks would violate the model. 638 5.5.2.2. Non-MAC-Aware Server 640 A process on the client labeled Secret wishes to access a directory 641 which the client's policies label as Top Secret on the server. This 642 is denied since Secret does not dominate Top Secret. Note that there 643 will not be NFSv4.2 operations issued. If the process had instead a 644 Top Secret process label, the client would issue NFSv4.2 operations 645 to access the directory on the server. 647 5.5.3. MAC-Functional Server 649 With a MAC-Functional server and a client which is not, the client 650 behaves as if it were in a normal NFSv4.2 environment. Since the 651 process on the client does not provide a security attribute the 652 server must define a mechanism for labeling all requests from a 653 client. Assume that the server is using the same criteria used in 654 the first example. The server sees the request as coming from a 655 subnet that is a Secret network. The server determines that all 656 clients on that subnet will have their requests labeled with Secret. 658 Since the directory on the server is labeled Top Secret and Secret 659 does not dominate Top Secret the server would fail the request with 660 NFS4ERR_ACCESS. 662 6. IANA Considerations 664 This document has no actions for IANA. 666 7. Security Considerations 668 7.1. Trust Needed for a Community 670 Labeled NFS is a transport mechanism for labels, a storage 671 requirement for labels, and a definition of how to interpret labels. 672 It defines the responsibilities of the client and the server in the 673 various permutations of being MAC-Functional. It does not however 674 dictate in any manner whether assumptions can be made about other 675 entities in the relationship. For example, it does not define 676 whether a MAC-Functional client can demand that a MAC-Aware server 677 only accept requests from other MAC-Functional clients. That is a 678 policy based in a MAC model and this document does not impose 679 policies on systems. 681 As the requirement is a policy, it can be met with the use of a MAC 682 model. Let L be a LFS which implements the Limited Server mode, 683 i.e., a MAC-Aware server connected to MAC-Functional clients. Then a 684 new LFS L' can be created which has the additional policy that the 685 MAC-Aware server MUST NOT accept any requests from a non-MAC- 686 Functional client. 688 7.2. Guest Modes 690 When either the client or server is operating in guest mode it is 691 important to realize that one side is not enforcing MAC protections. 692 Alternate methods are being used to handle the lack of MAC support 693 and care should be taken to identify and mitigate threats from 694 possible tampering outside of these methods. 696 7.3. MAC-Functional Client Configuration 698 We defined a MAC model as a access control decision made on a system 699 which normal users do not have the ability to override policies (see 700 Section 1). If the process labels are created solely on the client, 701 then if a malicious user has sufficient access on that client, the 702 Labeled NFS model is compromised. Note that this is no different 703 from: 705 o current implementations in which the server uses policies to 706 effectively determine the object label for requests from the 707 client, or 709 o local decisions made on the client by the MAC security system. 711 The server must either explicitly trust the client (as in [SENFSV3]) 712 or the MAC model should enforce that users cannot override policies, 713 perhaps via a externally managed source. 715 Once the labels leave the client, they can be protected by the 716 transport mechanism as described in Section 3.2. 718 8. References 720 8.1. Normative References 722 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 723 Requirement Levels", March 1997. 725 8.2. Informative References 727 [DTOS] Smalley, S., "The Distributed Trusted Operating System 728 (DTOS) Home Page ", December 2000, . 731 [I-D.ietf-nfsv4-minorversion2] 732 Haynes, T., "NFS Version 4 Minor Version 2", draft-ietf- 733 nfsv4-minorversion2-21 (Work In Progress), November 2013. 735 [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", 736 August 2007. 738 [RH_MLS] "Section 46.6. Multi-Level Security (MLS) of Deployment 739 Guide: Deployment, configuration and administration of Red 740 Hat Enterprise Linux 5, Edition 6 ", 2011. 742 [SENFSV3] Carter, J., "Implementing SELinux Support for NFS", , 743 . 746 [lfsreg] Quigley, D. and J. Lu, "Registry Specification for MAC 747 Security Label Formats", draft-quigley-label-format- 748 registry (work in progress), 2011. 750 [rpcsecgssv3] 751 Adamson, W. and N. Williams, "Remote Procedure Call (RPC) 752 Security Version 3", draft-ietf-nfsv4-rpcsec-gssv3-05 753 (Work In Progress), October 2013. 755 Appendix A. Acknowledgments 757 David Quigley was the early energy in motivating the entire Labeled 758 NFS effort. 760 James Morris, Jarrett Lu, and Stephen Smalley all were key 761 contributors to both early versions of this document and to many 762 conference calls. 764 Kathleen Moriarty provided use cases for earlier versions of the 765 draft. 767 Dan Walsh provided use cases for Secure Virtualization, Sandboxing, 768 and NFS homedir labeling to handle process separation. 770 Trond Myklebust provided use cases for secure diskless NFS clients. 772 Both Nico Williams and Bryce Nordgren challenged assumptions during 773 the review processes. 775 Appendix B. RFC Editor Notes 777 [RFC Editor: please remove this section prior to publishing this 778 document as an RFC] 780 [RFC Editor: prior to publishing this document as an RFC, please 781 replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the 782 RFC number of this document] 784 Author's Address 786 Thomas Haynes 787 NetApp 788 495 E Java Dr 789 Sunnyvale, CA 95054 790 USA 792 Phone: +1 408 419 3018 793 Email: thomas@netapp.com