idnits 2.17.1 draft-ietf-nfsv4-labreqs-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 02, 2012) is 4376 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' == Outdated reference: A later version (-41) exists of draft-ietf-nfsv4-minorversion2-08 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFSv4 T. Haynes, Ed. 3 Internet-Draft NetApp 4 Intended status: Standards Track May 02, 2012 5 Expires: November 3, 2012 7 Requirements for Labeled NFS 8 draft-ietf-nfsv4-labreqs-01.txt 10 Abstract 12 This Internet-Draft outlines high-level requirements for the 13 integration of flexible Mandatory Access Control (MAC) functionality 14 into NFSv4.2. It describes the level of protections that should be 15 provided over protocol components and the basic structure of the 16 proposed system. It also gives a brief explanation of what kinds of 17 protections MAC systems offer. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [1]. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 3, 2012. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3.1. Portability & Interoperability . . . . . . . . . . . . . . 5 75 3.2. Performance & Scalability . . . . . . . . . . . . . . . . 6 76 3.3. Security Services . . . . . . . . . . . . . . . . . . . . 6 77 3.4. Label Encoding, Label Format Specifiers, and Label 78 Checking Authorities . . . . . . . . . . . . . . . . . . . 7 79 3.5. Modes of Operation . . . . . . . . . . . . . . . . . . . . 8 80 3.5.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 8 81 3.5.2. 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 . . . . . . . . . . . . . . . . 16 103 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 104 5.1. Guest Modes . . . . . . . . . . . . . . . . . . . . . . . 16 105 5.2. MAC-Functional Client Configuration . . . . . . . . . . . 16 106 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 107 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 108 7.1. Normative References . . . . . . . . . . . . . . . . . . . 17 109 7.2. Informative References . . . . . . . . . . . . . . . . . . 17 110 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18 111 Appendix B. RFC Editor Notes . . . . . . . . . . . . . . . . . . 18 112 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 114 1. Introduction 116 Mandatory Access Control (MAC) systems have been mainstreamed in 117 modern operating systems such as Linux (R), FreeBSD (R), and Solaris 118 (TM). MAC systems bind security attributes to subjects (processes) 119 and objects within a system. These attributes are used with other 120 information in the system to make access control decisions. 122 Access control models such as Unix permissions or Access Control 123 Lists are commonly referred to as Discretionary Access Control (DAC) 124 models. These systems base their access decisions on user identity 125 and resource ownership. In contrast MAC models base their access 126 control decisions on the label on the subject (usually a process) and 127 the object it wishes to access. These labels may contain user 128 identity information but usually contain additional information. In 129 DAC systems users are free to specify the access rules for resources 130 that they own. MAC models base their security decisions on a system 131 wide policy established by an administrator or organization which the 132 users do not have the ability to override. DAC systems offer no real 133 protection against malicious or flawed software due to each program 134 running with the full permissions of the user executing it. 135 Inversely MAC models can confine malicious or flawed software and 136 usually act at a finer granularity than their DAC counterparts. 138 People desire to use NFSv4 with these systems. A mechanism is 139 required to provide security attribute information to NFSv4 clients 140 and servers. This mechanism has the following requirements: 142 (1) Clients must be able to convey to the server the security 143 attribute of the subject making the access request. The server 144 may provide a mechanism to enforce MAC policy based on the 145 requesting subject's security attribute. 147 (2) Servers must be able to store and retrieve the security 148 attribute of exported files as requested by the client. 150 (3) Servers must provide a mechanism for notifying clients of 151 attribute changes of files on the server. 153 (4) Clients and Servers must be able to negotiate Label Formats and 154 provide a mechanism to translate between them as needed. 156 2. Definitions 157 Label Format Specifier (LFS): is an identifier used by the client to 158 establish the syntactic format of the security label and the 159 semantic meaning of its components. These specifiers exist in a 160 registry associated with documents describing the format and 161 semantics of the label. 163 Label Format Registry: is the IANA registry (see [2]) containing all 164 registered LFS along with references to the documents that 165 describe the syntactic format and semantics of the security label. 167 Policy Identifier (PI): is an optional part of the definition of a 168 Label Format Specifier which allows for clients and server to 169 identify specific security policies. 171 Object: is a passive resource within the system that we wish to be 172 protected. Objects can be entities such as files, directories, 173 pipes, sockets, and many other system resources relevant to the 174 protection of the system state. 176 Subject: is an active entity, usually a process, which is requesting 177 access to an object. 179 MAC-Aware: is a server which can transmit and store object labels. 181 MAC-Functional: is a client or server which is LNFS enabled. Such a 182 system can interpret labels and apply policies based on the 183 security system. 185 Multi-Level Security (MLS): is a traditional model where objects are 186 given a sensitivity level (Unclassified, Secret, Top Secret, etc) 187 and a category set [5]. 189 3. Requirements 191 The following initial requirements have been gathered from users, 192 developers, and from previous development efforts in this area such 193 as DTOS [6] and NSA's experimental NFSv3 enhancements [7]. 195 3.1. Portability & Interoperability 197 LNFS must be designed with portability in mind, to facilitate 198 implementations on any operating system that supports mandatory 199 access controls. 201 LNFS must be designed and developed to facilitate interoperability 202 between different LNFS implementations. 204 LNFS modifications to standard NFSv4.2 [3] implementations must not 205 adversely impact any existing interoperability of those 206 implementations. 208 3.2. Performance & Scalability 210 Security mechanisms often impact on system performance. LNFS should 211 be designed and implemented in a way which avoids significant 212 performance impact where possible. 214 As NFSv4.2 is designed for large-scale distributed networking, LNFS 215 should also be capable of scaling in a similar manner to underlying 216 implementations where possible. 218 LNFS should respond in a robust manner to system and network outages 219 associated with typical enterprise and Internet environments. At the 220 very least, LNFS should always operate in a fail-safe manner, so that 221 service disruptions do not cause or facilitate security 222 vulnerabilities. 224 3.3. Security Services 226 LNFS should ensure that the following security services are provided 227 for all NFSv4.2 messaging. These services may be provided by lower 228 layers even if NFS has to be aware of and leverage them: 230 o Authentication 232 o Integrity 234 o Privacy 236 Mechanisms and algorithms used in the provision of security services 237 must be configurable, so that appropriate levels of protection may be 238 flexibly specified per mandatory security policy. 240 Strong mutual authentication will be required between the server and 241 the client for Full Mode operation Section 3.5.1. 243 MAC security labels and any related security state must always be 244 protected by these security services when transferred over the 245 network; as must the binding of labels and state to associated 246 objects and subjects. 248 LNFS should support authentication on a context granularity so that 249 different contexts running on a client can use different 250 cryptographic keys and facilities. 252 3.4. Label Encoding, Label Format Specifiers, and Label Checking 253 Authorities 255 Encoding of MAC labels and attributes passed over the network must be 256 specified in a complete and unambiguous manner while maintaining the 257 flexibility of MAC implementations. To accomplish this the labels 258 should consist of an opaque component bound with a Label Format 259 Specifier (LFS). The LFS component provides a mechanism for 260 identifying the structure and semantics of the opaque component. 261 Meanwhile, the opaque component is the security label which will be 262 interpreted by the MAC models. 264 MAC models base access decisions on security attributes bound to 265 subjects and objects. With a given MAC model, all systems have 266 semantically coherent labeling - a security label must always mean 267 exactly the same thing on every system. While this may not be 268 necessary for simple MAC models it is recommended that most label 269 formats assigned an LFS incorporate this concept into their label 270 format. 272 LNFS must provide a means for servers and clients to identify their 273 LFS for the purposes of authorization, security service selection, 274 and security label interpretation. 276 A negotiation scheme should be provided, allowing systems from 277 different label formats to agree on how they will interpret or 278 translate each others labels. Multiple concurrent agreements may be 279 current between a server and a client. 281 All security labels and related security state transferred across the 282 network must be tagged with a valid LFS. 284 If the LFS supported on a system changes, it should renegotiate 285 agreements to reflect these changes. 287 If a system receives any security label or security state tagged with 288 an LFS it does not recognize or cannot interpret, it must reject that 289 label or state. 291 NFSv4.2 includes features which may cause a client to cross an LFS 292 boundary when accessing what appears to be a single file system. If 293 LFS negotiation is supported by the client and the server, the server 294 should negotiate a new, concurrent agreement with the client, acting 295 on behalf of the externally located source of the files. 297 LNFS should define an initial negotiation scheme with the primary 298 aims of simplicity and completeness. This is to facilitate practical 299 deployment of systems without being weighed down by complex and over- 300 generalized global schemes. Future extensibility should also be 301 taken into consideration. 303 3.5. Modes of Operation 305 LNFS must cater for two potentially concurrent operating modes, 306 depending on the state of MAC functionality: 308 3.5.1. Full Mode 310 The server and the client have mutually recognized MAC functionality 311 enabled, and full LNFS functionality is extended over the network 312 between both client and server. 314 An example of an operation in full mode is as follows. On the 315 initial lookup, the client requests access to an object on the 316 server. It sends its process security context over to the server. 317 The server checks all relevant policies to determine if that process 318 context from that client is allowed to access the resource. Once 319 this has succeeded the object with its associated security 320 information is released to the client. Once the client receives the 321 object it determines if its policies allow the process running on the 322 client access to the object. 324 On subsequent operations where the client already has a handle for 325 the file, the order of enforcement is reversed. Since the client 326 already has the security context it may make an access decision 327 against its policy first. This enables the client to avoid sending 328 requests to the server that it knows will fail regardless of the 329 server's policy. If the client passes its policy checks then it 330 sends the request to the server where the client's process context is 331 used to determine if the server will release that resource to the 332 client. If both checks pass, the client is given the resource and 333 everything succeeds. 335 In the event that the client does not trust the server, it may opt to 336 use an alternate labeling mechanism regardless of the server's 337 ability to return security information. 339 3.5.2. Guest Mode 341 Only one of the server or client is MAC-Functional enabled. 343 In the case of the server only being MAC-Functional, the server 344 locally enforces its policy, and may selectively provide standard NFS 345 services to clients based on their authentication credentials and/or 346 associated network attributes (e.g., IP address, network interface) 347 according to security policy. The level of trust and access extended 348 to a client in this mode is configuration-specific. 350 In the case of the client only being MAC-Functional, the client must 351 operate as a standard NFSv4.2 client, and should selectively provide 352 processes access to servers based upon the security attributes of the 353 local process, and network attributes of the server, according to 354 policy. The client may also override default labeling of the remote 355 file system based upon these security attributes, or other labeling 356 methods such as mount point labeling. 358 In other words, Guest Mode is standard NFSv4.2 over the wire, with 359 the MAC-Functional system mapping the non-MAC-Functional system's 360 processes or objects to security labels based on other 361 characteristics in order to preserve its MAC guarantees. 363 3.6. Labeling 365 Implementations must validate security labels supplied over the 366 network to ensure that they are within a set of labels permitted from 367 a specific peer, and if not, reject them. Note that a system may 368 permit a different set of labels to be accepted from each peer. 370 3.6.1. Client Labeling 372 At the client, labeling semantics for NFS mounted file systems must 373 remain consistent with those for locally mounted file systems. In 374 particular, user-level labeling operations local to the client must 375 be enacted locally via existing APIs, to ensure compatibility and 376 consistency for applications and libraries. 378 Note that this does not imply any specific mechanism for conveying 379 labels over the network. 381 When an object is newly created by the client, it will calculate the 382 label for the object based on its policy. Once that is done it will 383 send the request to the server which has the ability to deny the 384 creation of the object with that label based on the server's policy. 385 In creating the file the server must ensure that the label is bound 386 to the object before the object becomes visible to the rest of the 387 system. This ensures that any access control or further labeling 388 decisions are correct for the object. 390 3.6.2. Server Labeling 392 The server must provide the capability for clients to retrieve 393 security labels on all exported file system objects where possible. 394 This includes cases where only in-core and/or read-only security 395 labels are available at the server for any of its exported file 396 systems. 398 The server must honor the ability for a client to specify the label 399 of an object on creation. If the server is MAC enabled it may choose 400 to reject the label specified by the client due to restrictions in 401 the server policy. The server should not attempt to find a suitable 402 label for an object in event of different labeling rules on its end. 403 The server is allowed to translate the label but should not change 404 the semantic meaning of the label. 406 3.7. Policy Enforcement 408 3.7.1. Full Mode 410 The server must enforce its security policy over all exported 411 objects, for operations which originate both locally and remotely. 413 Requests from authenticated clients must be processed using security 414 labels and credentials supplied by the client as if they originated 415 locally. 417 As with labeling, the system must also take into account any other 418 volatile client security state, such as a change in process security 419 context via dynamic transition. Access decisions should also be made 420 based upon the current client security label accessing the object, 421 rather than the security label which opened it, if different. 423 The client must apply its own policy to remotely located objects, 424 using security labels for the objects obtained from the server. It 425 must be possible to configure the maximum length of time a client may 426 cache state regarding remote labels before re-validating that state 427 with the server. 429 The server must recall delegation of an object if the object's 430 security label changes. 432 A mechanism must exist to allow the client to obtain access, and 433 labeling decisions from the server for locally cached and delegated 434 objects, so that it may apply the server's policy to these objects. 435 If the server's policy changes, the client must flush all object 436 state back to the server. The server must ensure that any flushed 437 state received is consistent with current policy before committing it 438 to stable storage. 440 Any local security state associated with cached or delegated objects 441 must also be flushed back to the server when any other state of the 442 objects is required to be flushed back. 444 3.7.2. Guest Mode 446 If the server is MAC-Functional and the client is not, the server 447 must not accept security labels provided by the client, and only 448 enforce its policy to exported objects. In the event that the client 449 is MAC-Functional while the server is not then the client may deny 450 access or fall back on other methods for providing security labeling. 452 3.8. Namespace Access 454 The server should provide a means to authorize selective access to 455 the exported file system namespace based upon client credentials and 456 according to security policy. 458 This is a common requirement of MLS-enabled systems, which often need 459 to present selective views of namespaces based upon the clearances of 460 the subjects. 462 3.9. Upgrading Existing Server 464 Note that under the MAC model, all objects must have labels. 465 Therefore, if an existing server is upgraded to include LNFS support, 466 then it is the responsibility of the security system to define the 467 behavior for existing objects. For example, if the security system 468 is that the server just stores and returns labels, then existing 469 files should return labels which are set to an empty value. 471 4. Use Cases 473 MAC labeling is meant to allow NFSv4.2 to be deployed in site 474 configurable security schemes. The LFS and opaque data scheme allows 475 for flexibility to meet these different implementations. In this 476 section, we provide some examples of how NFSv4.2 could be deployed to 477 meet existing needs. This is not an exhaustive listing. 479 4.1. Full MAC labeling support for remotely mounted filesystems 481 In this case, we assume a local networked environment where the 482 servers and clients are under common administrative control. All 483 systems in this network have the same MAC implementation and 484 semantically identical MAC security labels for objects (i.e. labels 485 mean the same thing on different systems, even if the policies on 486 each system may differ to some extent). Clients will be able to 487 apply fine-grained MAC policy to objects accessed via NFS mounts, and 488 thus improve the overall consistency of MAC policy application within 489 this environment. 491 An example of this case would be where user home directories are 492 remotely mounted, and fine-grained MAC policy is implemented to 493 protect, for example, private user data from being read by malicious 494 web scripts running in the user's browser. With Labeled NFS, fine- 495 grained MAC labeling of the user's files will allow the MAC policy to 496 be implemented and provide the desired protection. 498 4.2. MAC labeling of virtual machine images stored on the network 500 Virtualization is now a commonly implemented feature of modern 501 operating systems, and there is a need to ensure that MAC security 502 policy is able to protect virtualized resources. A common 503 implementation scheme involves storing virtualized guest filesystems 504 on a networked server, which are then mounted remotely by guests upon 505 instantiation. In this case, there is a need to ensure that the 506 local guest kernel is able to access fine-grained MAC labels on the 507 remotely mounted filesystem so that its MAC security policy can be 508 applied. 510 4.3. International Traffic in Arms Regulations (ITAR) 512 The International Traffic in Arms Regulations (ITAR) is put forth by 513 the United States Department of State, Directorate of Defense and 514 Trade Controls. ITAR places strict requirements on the export and 515 thus access of defense articles and defense services. Organizations 516 that manage projects with articles and services deemed as within the 517 scope of ITAR must ensure the regulations are met. The regulations 518 require an assurance that ITAR information is accessed on a need-to- 519 know basis, thus requiring strict, centrally managed access controls 520 on items labeled as ITAR. Additionally, organizations must be able 521 to prove that the controls were adequately maintained and that 522 foreign nationals were not permitted access to these defense articles 523 or service. ITAR control applicability may be dynamic; information 524 may become subject to ITAR after creation (e.g., when the defense 525 implications of technology are recognized). 527 4.4. Legal Hold/eDiscovery 529 Increased cases of legal holds on electronic sources of information 530 (ESI) have resulted in organizations taking a pro-active approach to 531 reduce the scope and thus costs associated with these activities. 532 ESI Data Maps are increasing in use and require support in operating 533 systems to strictly manage access controls in the case of a legal 534 hold. The sizeable quantity of information involved in a legal 535 discovery request may preclude making a copy of the information to a 536 separate system that manages the legal hold on the copies; this 537 results in a need to enforce the legal hold on the original 538 information. 540 Organizations are taking steps to map out the sources of information 541 that are most likely to be placed under a legal hold, these efforts 542 result in ESI Data Maps. ESI Data Maps specify the Electronic Source 543 of Information and the requirements for sensitivity and criticality. 544 In the case of a legal hold, the ESI data map and labels can be used 545 to ensure the legal hold is properly enforced on the predetermined 546 set of information. An ESI data map narrows the scope of a legal 547 hold to the predetermined ESI. The information must then be 548 protected at a level of security of which the weight and 549 admissibility of that evidence may be proved in a court of law. 550 Current systems use application level controls and do not adequately 551 meet the requirements. Labels may be used in advance when an ESI 552 data map exercise is conducted with controls being applied at the 553 time of a hold or labels may be applied to data sets during an 554 eDiscovery exercise to ensure the data protections are adequate 555 during the legal hold period. 557 Note that this use case requires multi-attribute labels, as both 558 information sensitivity (e.g., to disclosure) and information 559 criticality (e.g., to continued business operations) need to be 560 captured. 562 4.5. Simple security label storage 564 In this case, a mixed and loosely administered network is assumed, 565 where nodes may be running a variety of operating systems with 566 different security mechanisms and security policies. It is desired 567 that network file servers be simply capable of storing and retrieving 568 MAC security labels for clients which use such labels. The LNFS 569 protocol would be implemented here solely to enable transport of MAC 570 security labels across the network. It should be noted that in such 571 an environment, overall security cannot be as strongly enforced as 572 when the server is also enforcing, and that this scheme is aimed at 573 allowing MAC-capable clients to function with its MAC security policy 574 enabled rather than perhaps disabling it entirely. 576 4.6. Diskless Linux 578 A number of popular operating system distributions depend on a 579 mandatory access control (MAC) model to implement a kernel-enforced 580 security policy. Typically, such models assign particular roles to 581 individual processes, which limit or permit performing certain 582 operations on a set of files, directories, sockets, or other objects. 583 While the enforcing of the policy is typically a matter for the 584 diskless NFS client itself, the filesystem objects in such models 585 will typically carry MAC labels that are used to define policy on 586 access. These policies may, for instance, describe privilege 587 transitions that cannot be replicated using standard NFS ACL based 588 models. 590 For instance on a SYSV compatible system, if the 'init' process 591 spawns a process that attempts to start the 'NetworkManager' 592 executable, there may be a policy that sets up a role transition if 593 the 'init' process and 'NetworkManager' file labels match a 594 particular rule. Without this role transition, the process may find 595 itself having insufficient privileges to perform its primary job of 596 configuring network interfaces. 598 In setups of this type, a lot of the policy targets (such as sockets 599 or privileged system calls) are entirely local to the client. The 600 use of RPCSEC_GSSv3 ([4]) for enforcing compliance at the server 601 level is therefore of limited value. The ability to permanently 602 label files and have those labels read back by the client is, 603 however, crucial to the ability to enforce that policy. 605 4.7. Multi-Level Security 607 In a MLS system objects are generally assigned a sensitivity level 608 and a set of compartments. The sensitivity levels within the system 609 are given an order ranging from lowest to highest classification 610 level. Read access to an object is allowed when the sensitivity 611 level of the subject "dominates" the object it wants to access. This 612 means that the sensitivity level of the subject is higher than that 613 of the object it wishes to access and that its set of compartments is 614 a super-set of the compartments on the object. 616 The rest of the section will just use sensitivity levels. In general 617 the example is a client that wishes to list the contents of a 618 directory. The system defines the sensitivity levels as Unclassified 619 (U), Secret (S), and Top Secret (TS). The directory to be searched 620 is labeled Top Secret which means access to read the directory will 621 only be granted if the subject making the request is also labeled Top 622 Secret. 624 4.7.1. Full Mode - MAC-functional Client and Server 626 In the first part of this example a process on the client is running 627 at the Secret level. The process issues a readdir() system call 628 which enters the kernel. Before translating the readdir() system 629 call into a request to the NFSv4.2 server the host operating system 630 will consult the MAC module to see if the operation is allowed. 631 Since the process is operating at Secret and the directory to be 632 accessed is labeled Top Secret the MAC module will deny the request 633 and an error code is returned to user space. 635 Consider a second case where instead of running at Secret the process 636 is running at Top Secret. In this case the sensitivity of the 637 process is equal to or greater than that of the directory so the MAC 638 module will allow the request. Now the readdir() is translated into 639 the necessary NFSv4.2 call to the server. For the RPC request the 640 client is using the proper credential to assert to the server that 641 the process is running at Top Secret. 643 When the server receives the request it extracts the security label 644 from the RPC session and retrieves the label on the directory. The 645 server then checks with its MAC module if a Top Secret process is 646 allowed to read the contents of the Top Secret directory. Since this 647 is allowed by the policy then the server will return the appropriate 648 information back to the client. 650 In this example the policy on the client and server were both the 651 same. In the event that they were running different policies a 652 translation of the labels might be needed. In this case it could be 653 possible for a check to pass on the client and fail on the server. 654 The server may consider additional information when making its policy 655 decisions. For example the server could determine that a certain 656 subnet is only cleared for data up to Secret classification. If that 657 constraint was in place for the example above the client would still 658 succeed, but the server would fail since the client is asserting a 659 label that it is not able to use (Top Secret on a Secret network). 661 4.7.2. MAC-Functional Client 663 In these scenarios, the server is either non-MAC-Aware or MAC-Aware. 664 The actions of the client will depend whether it is configured to 665 treat the MAC-Aware server in the same manner as the non-MAC-Aware 666 one. I.e., does it utilize the approach presented in Section 3.5.2 667 or does it allow the MAC-Aware server to return labels? 669 With a client that is MAC-Functional and using the example in the 670 previous section, the result should be the same. The one difference 671 is that all decisions are made on the client. 673 4.7.2.1. MAC-Aware Server 675 A process on the client labeled Secret wishes to access a directory 676 labeled Top Secret on the server. This is denied since Secret does 677 not dominate Top Secret. Note that there will be NFSv4.2 operations 678 issued that return an object label for the client to process. 680 Note that in this scenario, all of the clients must be MAC- 681 Functional. A single client which does not do its access control 682 checks would violate the model. 684 4.7.2.2. Non-MAC-Aware Server 686 A process on the client labeled Secret wishes to access a directory 687 which the client's policies label as Top Secret on the server. This 688 is denied since Secret does not dominate Top Secret. Note that there 689 will not be NFSv4.2 operations issued. If the process had instead a 690 Top Secret process label, the client would issue NFSv4.2 operations 691 to access the directory on the server. 693 4.7.3. MAC-Functional Server 695 With a MAC-Functional server and a client which is not, the client 696 behaves as if it were in a normal NFSv4.2 environment. Since the 697 process on the client does not provide a security attribute the 698 server must define a mechanism for labeling all requests from a 699 client. Assume that the server is using the same criteria used in 700 the first example. The server sees the request as coming from a 701 subnet that is a Secret network. The server determines that all 702 clients on that subnet will have their requests labeled with Secret. 703 Since the directory on the server is labeled Top Secret and Secret 704 does not dominate Top Secret the server would fail the request with 705 NFS4ERR_ACCESS. 707 5. Security Considerations 709 5.1. Guest Modes 711 When either the client or server is operating in guest mode it is 712 important to realize that one side is not enforcing MAC protections. 713 Alternate methods are being used to handle the lack of MAC support 714 and care should be taken to identify and mitigate threats from 715 possible tampering outside of these methods. 717 5.2. MAC-Functional Client Configuration 719 We defined a MAC model as a access control decision made on a system 720 which normal users do not have the ability to override policies (see 721 Section 1). If the process labels are created solely on the client, 722 then if a malicious user has sufficient access on that client, the 723 LNFS model is compromised. Note that this is no different from: 725 o current implementations in which the server uses policies to 726 effectively determine the object label for requests from the 727 client, or 729 o local decisions made on the client by the MAC security system. 731 The server must either explicitly trust the client (as in [7]) or the 732 MAC model should enforce that users cannot override policies, perhaps 733 via a externally managed source. 735 Once the labels leave the client, they can be protected by the 736 transport mechanism as described in Section 3.3. 738 6. IANA Considerations 740 It is requested that IANA creates a registry of Label Formats to 741 describe the syntactic format and semantics of the security label 742 (see [2]). 744 7. References 746 7.1. Normative References 748 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 749 Levels", March 1997. 751 [2] Quigley, D. and J. Lu, "Registry Specification for MAC Security 752 Label Formats", draft-quigley-label-format-registry (work in 753 progress), 2011. 755 [3] Haynes, T., "NFS Version 4 Minor Version 2", 756 draft-ietf-nfsv4-minorversion2-08 (Work In Progress), 757 March 2011. 759 [4] Haynes, T. and N. Williams, "Remote Procedure Call (RPC) 760 Security Version 3", draft-williams-rpcsecgssv3 (work in 761 progress), 2011. 763 7.2. Informative References 765 [5] "Section 46.6. Multi-Level Security (MLS) of Deployment Guide: 766 Deployment, configuration and administration of Red Hat 767 Enterprise Linux 5, Edition 6", 2011. 769 [6] Smalley, S., "The Distributed Trusted Operating System (DTOS) 770 Home Page", 771 . 773 [7] Carter, J., "Implementing SELinux Support for NFS", 774 . 776 Appendix A. Acknowledgments 778 David Quigley was the early energy in motivating the entire LNFS 779 effort. 781 James Morris, Jarrett Lu, and Stephen Smalley all were key 782 contributors to both early versions of this document and to many 783 conference calls. 785 Kathleen Moriarty provided the use cases for ITAR and Legal Hold/ 786 eDiscovery. 788 Dan Walsh provided use cases for Secure Virtualization, Sandboxing, 789 and NFS homedir labeling to handle process separation. 791 Trond Myklebust provided use cases for secure diskless NFS clients. 793 Both Nico Williams and Bryce Nordgren challenged assumptions during 794 the review processes. 796 Appendix B. RFC Editor Notes 798 [RFC Editor: please remove this section prior to publishing this 799 document as an RFC] 801 [RFC Editor: prior to publishing this document as an RFC, please 802 replace all occurrences of RFCTBD10 with RFCxxxx where xxxx is the 803 RFC number of this document] 805 Author's Address 807 Thomas Haynes (editor) 808 NetApp 809 9110 E 66th St 810 Tulsa, OK 74133 811 USA 813 Phone: +1 918 307 1415 814 Email: thomas@netapp.com