idnits 2.17.1 draft-quigley-nfsv4-sec-label-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (February 23, 2010) is 5175 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2434' is defined on line 530, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Quigley 3 Internet-Draft NSA 4 Intended status: Standards Track J. Morris 5 Expires: August 27, 2010 Red Hat, Inc. 6 February 23, 2010 8 MAC Security Label Support for NFSv4 9 draft-quigley-nfsv4-sec-label-01.txt 11 Abstract 13 This Internet-Draft describes additions to NFSv4 minor version one to 14 support Mandatory Access Control systems. The current draft 15 describes the mechanism for transporting a MAC security label using 16 the NFSv4.1 protocol and the semantics required for that label. In 17 addition to this it describes an example system of using this label 18 in a fully MAC aware environment. 20 Status of this Memo 22 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 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 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on August 27, 2010. 43 Copyright Notice 45 Copyright (c) 2010 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 62 3. MAC Security Attribute . . . . . . . . . . . . . . . . . . . . 4 63 3.1. Interpreting security_attribute . . . . . . . . . . . . . 5 64 3.2. Delegations . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.3. Permission Checking . . . . . . . . . . . . . . . . . . . 6 66 3.4. Object Creation . . . . . . . . . . . . . . . . . . . . . 6 67 4. MAC Security NFS Modes of Operation . . . . . . . . . . . . . 6 68 4.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.1.1. Initial Labeling and Translation . . . . . . . . . . . 7 70 4.1.2. Policy Enforcement . . . . . . . . . . . . . . . . . . 7 71 4.2. Smart Client Mode . . . . . . . . . . . . . . . . . . . . 8 72 4.2.1. Initial Labeling and Translation . . . . . . . . . . . 8 73 4.2.2. Policy Enforcement . . . . . . . . . . . . . . . . . . 8 74 4.3. Smart Server Mode . . . . . . . . . . . . . . . . . . . . 9 75 4.3.1. Initial Labeling and Translation . . . . . . . . . . . 9 76 4.3.2. Policy Enforcement . . . . . . . . . . . . . . . . . . 9 77 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 5.1. Multi-Level Security . . . . . . . . . . . . . . . . . . . 10 79 5.1.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 10 80 5.1.2. Smart Client Mode . . . . . . . . . . . . . . . . . . 11 81 5.1.3. Smart Server Mode . . . . . . . . . . . . . . . . . . 11 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 8. Normative References . . . . . . . . . . . . . . . . . . . . . 12 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Introduction 89 Mandatory Access Control (MAC) systems have been mainstreamed in 90 modern operating systems such as Linux (R), FreeBSD (R), Solaris 91 (TM), and Windows Vista (R). MAC systems bind security attributes to 92 subjects (processes) and objects within a system. These attributes 93 are used with other information in the system to make access control 94 decisions. 96 Access control models such as Unix permissions or Access Control 97 Lists are commonly refered to as Discretionary Access Control (DAC) 98 models. These systems base their access decisions on user identity 99 and resource ownership. In contrast MAC models base their access 100 control decisions on the label on the subject (usually a process) and 101 the object it wishes to access. These labels may contain user 102 identity information but usually contain additional information. In 103 DAC systems users are free to specify the access rules for resources 104 that they own. MAC models base their security decisions on a system 105 wide policy established by an administrator or organization which the 106 users do not have the ability to override. DAC systems offer no real 107 protection against malicious or flawed software due to each program 108 running with the full permissions of the user executing it. 109 Inversely MAC models can confine malicious of flawed software and 110 usually act at a finer granularity than their DAC counterparts. 112 People desire to use NFSv4 with these systems. A mechanism is 113 required to provide security attribute information to NFSv4 clients 114 and servers. This mechanism has the following requirements: 116 o Clients must be able to convey to the server the security 117 attribute of the subject making the access request. The server 118 may provide a mechanism to enforce MAC policy based on the 119 requesting subject's security attribute. 121 o Server must be able to store and retrieve the security attribute 122 of exported files as requested by the client. 124 o Server must provide a mechanism for notifying clients of attribute 125 changes of files on the server. 127 o Clients and Servers must be able to negotiate Label Formats and 128 Domains of Interpretation (DOI) and provide a mechanism to 129 translate between them as needed. 131 These four requirements are key to the system with only requirements 132 two and three requiring changes to NFSv4.1. The ability to convey 133 the security attribute of the subject as described in requirement one 134 falls upon the RPC layer to implement. Requirement four allows 135 communication between different MAC implementations. The management 136 of label formats, DOIs and the translation between them does not 137 require any support from NFS on a protocol level and is out of the 138 scope of this document. 140 2. Terms and Definitions 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC2119]. 146 Label Format Specifier: An identifier used by the client to establish 147 the syntactic format of the security label and the semantic meaning 148 of its components. These specifiers exist in a registry associated 149 with documents describing the format and semantics of the label. 151 Label Format Registry: The IANA registry containing all registered 152 Label Format Specifiers along with references to the documents that 153 describe the syntactic format and semantics of the security label. 155 Policy Identifier: An optional part of the definition of a Label 156 Format Specifier which allows for clients and server to identify 157 specific security policies. 159 Domain of Interpretation: A Domain of Interpretation (DOI) represents 160 an administrative security boundary, where all systems within the DOI 161 have semantically coherent labeling. That is, a security attribute 162 must always mean exactly the same thing anywhere within the DOI. 164 Object: An object is a passive resource within the system that we 165 wish to be protected. Objects can be entities such as files, 166 directories, pipes, sockets, and many other system resources relevant 167 to the protection of the system state. 169 Subject: A subject is an active entity usually a process which is 170 requesting access to an object. 172 3. MAC Security Attribute 174 MAC models base access decisions on security attributes bound to 175 subjects and objects. This information can range from a user 176 identity for an identity based MAC model, sensitivity levels for 177 Multi-level security, or a type for Type Enforcement. These models 178 base their decisions on different criteria but the semantics of the 179 security attribute remain the same. The semantics required by the 180 security attributes are listed below: 182 o Must provide flexibility with respect to MAC model. 184 o Must provide the ability to atomically set security information 185 upon object creation 187 o Must provide the ability to enforce access control decisions both 188 on the client and the server 190 o Must not expose an object to either the client or server name 191 space before its security information has been bound to it. 193 NFSv4 provides several options for implementing the security 194 attribute. The first option is to implement the security attribute 195 as a named attribute. Named attributes provide flexibility since 196 they are treated as an opaque field but lack a way to atomically set 197 the attribute on creation. In addition, named attributes themselves 198 are file system objects which need to be assigned a security 199 attribute. This raises the question of how to assign security 200 attributes to the file and directories used to hold the security 201 attribute for the file in question. The inability to atomically 202 assign the security attribute on file creation and the necessity to 203 assign security attributes to its subcomponents makes named 204 attributes unacceptable as a method for storing security attributes. 206 The second option is to implement the security attribute as a 207 recommended attribute as defined in section 5.2 of RFC 3530. 208 Recommended attributes have a fixed format and semantics, which 209 conflicts with the flexible nature of the security attribute. To 210 resolve this the security attribute consists of two components. The 211 first component is a Label Format Specifier(LFS) as defined in [XXX: 212 Insert Doc here] to allow for interoperability between MAC 213 mechanisms. The second component is an opaque field which the actual 214 security attribute data. To allow for various MAC models NFSv4 215 should be used solely as a transport mechanism for the security 216 attribute. It is the responsibility of the endpoints to consume the 217 security attribute and make access decisions based on their 218 respective models. In addition, creation of objects through OPEN and 219 CREATE allows for the security attribute to be specified upon 220 creation. By providing an atomic create and set operation for the 221 security attribute it is possible to enforce the second and fourth 222 requirements. To this end the attribute number XXX:ATTRNUM is 223 requested for the security_attribute recommended attribute. 225 3.1. Interpreting security_attribute 227 The security_attribute field contains two components the first 228 component being an LFS. The LFS serves to provide the receiving end 229 with the information necessary to translate the security attribute 230 into a form that is usable by the endpoint. Label Formats assigned 231 an LFS may optionally choose to include a Policy Identifier (PI) 232 field to allow for complex policy deployments. The Label Format 233 Specifier and Label Format Registry are described in detail in [XXX: 234 Insert RFC Here]. The translation used to interpret the security 235 attribute is not specified as part of the protocol as it may depend 236 on various factors. The second component is an opaque section which 237 contains the data of the attribute. This component is dependent on 238 the MAC model to interpret and enforce. The character '@' is 239 reserved as a separator between the LFS and opaque section of the 240 security attribute. 242 3.2. Delegations 244 In the event that a security attribute is changed on the server while 245 a client holds a delegation on the file, the client should follow the 246 existing protocol with respect to attribute changes. It should flush 247 all changes back to the server and relinquish the delegation. 249 3.3. Permission Checking 251 It is not feasible to enumerate all possible MAC models and even 252 levels of protection within a subset of these models. This means 253 that the NFSv4 client and servers can not be expected to directly 254 make access control decisions based on the security attribute. 255 Instead NFSv4 should defer permission checking on this attribute to 256 the host system. These checks are performed in addition to existing 257 DAC and ACL checks outlined in the NFSv4 protocol. Section 4 gives a 258 specific example of how the security attribute is handled under a 259 particular MAC model. 261 3.4. Object Creation 263 When creating files in NFSv4 the OPEN and CREATE operations are used. 264 One of the parameters to these operations is an fattr4 structure 265 containing the attributes the file is to be created with. This 266 allows NFSv4 to atomically set the security attribute of files upon 267 creation. When a client is MAC aware it must always provide the 268 initial security attribute upon file creation. In the event that the 269 server is the only MAC aware entity in the system it should ignore 270 the security attribute specified by the client and instead make the 271 determination itself. A more in depth explanation can be found in 272 Section 4. 274 4. MAC Security NFS Modes of Operation 276 A system using Labeled NFS may operate in three modes. The first 277 mode provides the most protection and is called "full" mode. In this 278 mode both the client and server implement a MAC model allowing each 279 end to make an access control decision. The remaining two modes are 280 variations on each other and are called "smart client" and "smart 281 server" modes. In these modes one end of the connection is not 282 implementing a MAC model and because of this these operating modes 283 offer less protection than full mode. 285 4.1. Full Mode 287 Full mode environments consist of MAC aware NFSv4 servers and clients 288 and may be composed of mixed MAC models and policies. The system 289 requires that both the client and server have an opportunity to 290 perform an access control check based on all relevant information 291 within the network. The file object security attribute is provided 292 using the mechanism described in Section 3. The security attribute 293 of the subject making the request is transported at the RPC layer 294 using the mechanism described in XXX: Insert RFC for RPC layer label 295 draft. 297 4.1.1. Initial Labeling and Translation 299 The ability to create a file is an action that a MAC model may wish 300 to mediate. The client is given the responsibility to determine the 301 initial security attribute to be placed on a file. This allows the 302 client to make a decision as to the acceptable security attributes to 303 create a file with before sending the request to the server. Once 304 the server receives the creation request from the client it may 305 choose to evaluate if the security attribute is acceptable. 307 Security attributes on the client and server may vary based on MAC 308 model and policy. To handle this the security attribute field has an 309 LFS component. This component is a mechanism for the host to 310 identify the format and meaning of the opaque portion of the security 311 attribute. A full mode environment may contain hosts operating in 312 several different LFSs and DOIs. In this case a mechanism for 313 translating the opaque portion of the security attribute is needed. 314 The actual translation function will vary based on MAC model and 315 policy and is out of the scope of this document. If a translation is 316 unavailable for a given LFS and DOI then the request SHOULD be 317 denied. Another recource is to allow the host to provide a fallback 318 mapping for unknown security attributes. 320 4.1.2. Policy Enforcement 322 In full mode access control decisions are made by both the clients 323 and servers. When a client makes a request it takes the security 324 attribute from the requesting process and makes an access control 325 decision based on that attribute and the security attribute of the 326 object it is trying to access. If the client denies that access an 327 RPC call to the server is never made. If however the access is 328 allowed the client will make a call to the NFS server. 330 When the server receives the request from the client it extracts the 331 security attribute conveyed in the RPC request. The server then uses 332 this security attribute and the attribute of the object the client is 333 trying to access to make an access control decision. If the server's 334 policy allows this access it will fulfill the client's request, 335 otherwise it will return NFS4ERR_ACCESS 337 Implementations MAY validate security attributes supplied over the 338 network to ensure that they are within a set of attributes permitted 339 from a specific peer, and if not, reject them. Note that a system 340 may permit a different set of attributes to be accepted from each 341 peer. An example of this can be seen in Section 5.1.1. 343 4.2. Smart Client Mode 345 Smart client environments consist of NFSv4 servers that are not MAC 346 aware but NFSv4 clients that are. Clients in this environment are 347 may consist of groups implementing different MAC models policies. 348 The system requires that all clients in the environment be 349 responsible for access control checks. Due to the amount of trust 350 placed in the clients this mode is only to be used in a trusted 351 environment. 353 4.2.1. Initial Labeling and Translation 355 Just like in full mode the client is responsible for determining the 356 initial label upon object creation. The server in smart client mode 357 does not implement a MAC model, however, it may provide the ability 358 to restrict the creation and labeling of object with certain labels 359 based on different criteria as described in Section 4.1.2. 361 In a smart client environment a group of clients operate in a single 362 DOI. This removes the need for the clients to maintain a set of DOI 363 translations. Servers should provide a method to allow different 364 groups of clients to access the server at the same time. However it 365 should not let two groups of clients operating in different DOIs to 366 access the same files. 368 4.2.2. Policy Enforcement 370 In smart client mode access control decisions are made by the 371 clients. When a client accesses an object it obtains the security 372 attribute of the object from the server and combines it with the 373 security attribute of the process making the request to make an 374 access control decision. This check is in addition to the DAC checks 375 provided by NFSv4 so this may fail based on the DAC criteria even if 376 the MAC policy grants access. As the policy check is located on the 377 client an access control denial should take the form that is native 378 to the platform. 380 4.3. Smart Server Mode 382 Smart server environments consist of NFSv4 servers that are MAC aware 383 and one or more MAC unaware clients. The server is the only entity 384 enforcing policy, and may selectively provide standard NFS services 385 to clients based on their authentication credentials and/or 386 associated network attributes (e.g. IP address, network interface). 387 The level of trust and access extended to a client in this mode is 388 configuration-specific. 390 4.3.1. Initial Labeling and Translation 392 In smart server mode all labeling and access control decisions are 393 performed by the NFSv4 server. In this environment the NFSv4 clients 394 are not MAC aware so they can not provide input into the access 395 control decision. This requires the server to determine the initial 396 labeling of objects. Normally the subject to use in this calculation 397 would originate from the client. Instead the NFSv4 server may choose 398 to assign the subject security attribute based on their 399 authentication credentials and/or associated network attributes (e.g. 400 IP address, network interface). 402 In smart server mode security attributes are contained solely within 403 the NFSv4 server. This means that all security attributes used in 404 the system remain within a single LFS and DOI. Since security 405 attributes will not cross DOIs or change format there is no need to 406 provide any translation functionality above that which is needed 407 internally by the MAC model. 409 4.3.2. Policy Enforcement 411 All access control decisions in smart server mode are made by the 412 server. The server will assign the subject a security attribute 413 based on some criteria (e.g. IP address, network interface). Using 414 the newly calculated security attribute and the security attribute of 415 the object being requested the MAC model makes the access control 416 check and returns NFS4ERR_ACCESS on a denial and NFS4_OK on success. 417 This check is done transparently to the client so if the MAC 418 permission check fails the client may be unaware of the reason for 419 the permission failure. When operating in this mode administrators 420 attempting to debug permission failures should be aware to check the 421 MAC policy running on the server in addition to the DAC settings. 423 5. Examples 425 The section below outlines an example of the Labeled NFS operation 426 modes using a traditional Multi Level Security(MLS) model where 427 objects are given a sensitivity level (Unclassified, Secret, Top 428 Secret etc..) and a category set. This is just one example of a 429 possible MAC model and is not required by labeled NFS 430 implementations. 432 5.1. Multi-Level Security 434 In a Multi-level security (MLS) system objects are generally assigned 435 a sensitivity level, and a set of compartments. The sensitivity 436 levels within the system are given an order ranging from lowest to 437 highest classification level. Read access to an object is allowed 438 when the sensitivity level of the subject "dominates" the object it 439 wants to access. This means that the sensitivity level of the 440 subject is higher than that of the object it wishes to access and 441 that its set of compartments is a super-set of the compartments on 442 the object. 444 The rest of the section will just use sensitivity levels. In general 445 the example is a client that wishes to list the contents of a 446 directory. The system defines the sensitivity levels 447 Unclassified(U), Secret(S), and Top Secret(TS). The directory to be 448 searched is labeled Top Secret which means access to read the 449 directory will only be granted if the subject making the request is 450 also labeled Top Secret. 452 5.1.1. Full Mode 454 In the first part of this example a process on the client is running 455 at the Secret level. The process issues a readdir system call which 456 enters the kernel. Before translating the readdir system call into a 457 request to the NFSv4 server the host operating system will consult 458 the MAC module to see if the operation is allowed. Since the process 459 is operating at Secret and the directory to be accessed is labeled 460 Top Secret the MAC module will deny the request and an error code is 461 returned to user space. 463 Consider a second case where instead of running at Secret the process 464 is running at Top Secret. In this case the sensitivity of the 465 process is equal to or greater than that of the directory so the MAC 466 module will allow the request. Now the readdir is translated into 467 the necessary NFSv4 call to the server. For the RPC request the 468 client is using the proper credential to assert to the server that 469 the process is running at Top Secret. 471 When the server receives the request it extracts the security label 472 from the RPC session and retrieves the label on the directory. The 473 server then checks with its MAC module if a Top Secret process is 474 allowed to read the contents of the Top Secret directory. Since this 475 is allowed by the policy then the server will return the appropriate 476 information back to the client. 478 In this example the policy on the client and server were both the 479 same. In the event that they were running different policies a 480 translation of the labels might be needed. In this case it could be 481 possible for a check to pass on the client and fail on the server. 482 The server may consider additional information when making its policy 483 decisions. For example the server could determine that a certain 484 subnet is only cleared for data up to Secret classification. If that 485 constraint was in place for the example above the client would still 486 succeed, but the server would fail since the client is asserting a 487 label that it is not able to use (Top Secret on a Secret network). 489 5.1.2. Smart Client Mode 491 In smart client mode the example is identical to the first part of a 492 full mode operation. A process on the client labeled Secret wishes 493 to access a Top Secret directory. As in the full mode example this 494 is denied since Secret does not dominate Top Secret. If the process 495 were operating at Top Secret it would pass the local access control 496 check and the NFSv4 operation would proceed as in a normal NFSv4 497 environment. 499 5.1.3. Smart Server Mode 501 In a smart server mode the client behaves as if it were in a normal 502 NFSv4 environment. Since the process on the client does not provide 503 a security attribute the server must define a mechanism for labeling 504 all requests from a client. Assume that the server is using the same 505 criteria used in the full mode example. The server sees the request 506 as coming from a subnet that is a Secret network. The server 507 determines that all clients on that subnet will have their requests 508 labeled with Secret. Since the directory on the server is labeled 509 Top Secret and Secret does not dominate Top Secret the server would 510 fail the request with NFS4ERR_ACCESS. 512 6. Security Considerations 514 Depending on the level of protection the MAC system offers there may 515 be a requirement to tightly bind the security attribute to the data. 516 It must be taken into consideration that when used in a pNFS 517 environment is it possible that the security attribute and file data 518 will be stored on separate servers. 520 7. IANA Considerations 522 XXX: Add section about LFS and LFS Registry referecing the other 523 document. 525 8. Normative References 527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 528 Requirement Levels", March 1997. 530 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 531 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 532 October 1998. 534 Authors' Addresses 536 David P. Quigley 537 National Security Agency 538 9800 Savage Rd. 539 Suite 6534 540 Ft. Meade, MD 20755-6534 542 Email: dpquigl@tycho.nsa.gov 544 James Morris 545 Red Hat, Inc. 547 Email: jmorris@namei.org