idnits 2.17.1 draft-quigley-nfsv4-sec-label-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 22, 2009) is 5573 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 499, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 1 error (**), 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: July 26, 2009 Red Hat, Inc. 6 January 22, 2009 8 MAC Security Label Support for NFSv4 9 draft-quigley-nfsv4-sec-label-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on July 26, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 This Internet-Draft describes additions to NFSv4 minor version one to 49 support Mandatory Access Control systems. The current draft 50 describes the mechanism for transporting a MAC security label using 51 the NFSv4.1 protocol and the semantics required for that label. In 52 addition to this it describes an example system of using this label 53 in a fully MAC aware environment. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 59 3. MAC Security Attribute . . . . . . . . . . . . . . . . . . . . 4 60 3.1. Interpreting security_attribute . . . . . . . . . . . . . 5 61 3.2. Delegations . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.3. Permission Checking . . . . . . . . . . . . . . . . . . . 5 63 3.4. Object Creation . . . . . . . . . . . . . . . . . . . . . 5 64 4. MAC Security NFS Modes of Operation . . . . . . . . . . . . . 6 65 4.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4.1.1. Initial Labeling and Translation . . . . . . . . . . . 6 67 4.1.2. Policy Enforcement . . . . . . . . . . . . . . . . . . 7 68 4.2. Smart Client Mode . . . . . . . . . . . . . . . . . . . . 7 69 4.2.1. Initial Labeling and Translation . . . . . . . . . . . 7 70 4.2.2. Policy Enforcement . . . . . . . . . . . . . . . . . . 8 71 4.3. Smart Server Mode . . . . . . . . . . . . . . . . . . . . 8 72 4.3.1. Initial Labeling and Translation . . . . . . . . . . . 8 73 4.3.2. Policy Enforcement . . . . . . . . . . . . . . . . . . 9 74 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 5.1. Multi-Level Security . . . . . . . . . . . . . . . . . . . 9 76 5.1.1. Full Mode . . . . . . . . . . . . . . . . . . . . . . 9 77 5.1.2. Smart Client Mode . . . . . . . . . . . . . . . . . . 10 78 5.1.3. Smart Server Mode . . . . . . . . . . . . . . . . . . 10 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 81 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 84 1. Introduction 86 Mandatory Access Control (MAC) systems have been mainstreamed in 87 modern operating systems such as Linux (R), FreeBSD (R), Solaris 88 (TM), and Windows Vista (R). MAC systems bind security attributes to 89 subjects (processes) and objects within a system. These attributes 90 are used with other information in the system to make access control 91 decisions. 93 People desire to use NFSv4 with these systems. A mechanism is 94 required to provide security attribute information to NFSv4 clients 95 and servers. This mechanism has the following requirements: 97 o Clients must be able to convey to the server the security 98 attribute of the subject making the access request. The server 99 may provide a mechanism to enforce MAC policy based on the 100 requesting subject's security attribute. 102 o Server must be able to store and retrieve the security attribute 103 of exported files as requested by the client. 105 o Server must provide a mechanism for notifying clients of attribute 106 changes of files on the server. 108 o Clients and Servers must be able to negotiate Domains of 109 Interpretation (DOI) and provide a mechanism to translate between 110 them as needed. 112 These four requirements are key to the system with only requirements 113 two and three requiring changes to NFSv4.1. The ability to convey 114 the security attribute of the subject as described in requirement one 115 falls upon the RPC layer to implement. Requirement four allows 116 communication between different MAC implementations. The management 117 of DOIs and the translation between them does not require any support 118 from NFS on a protocol level and is out of the scope of this 119 document. 121 2. Terms and Definitions 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 Domain of Interpretation: A Domain of Interpretation (DOI) represents 128 an administrative security boundary, where all systems within the DOI 129 have semantically coherent labeling. That is, a security attribute 130 must always mean exactly the same thing anywhere within the DOI. 132 Object: An object is a passive resource within the system that we 133 wish to be protected. Objects can be entities such as files, 134 directories, pipes, sockets, and many other system resources relevant 135 to the protection of the system state. 137 Subject: A subject is an active entity usually a process which is 138 requesting access to an object. 140 3. MAC Security Attribute 142 MAC models base access decisions on security attributes bound to 143 subjects and objects. This information can range from a user 144 identity for an identity based MAC model, sensitivity levels for 145 Multi-level security, or a type for Type Enforcement. These models 146 base their decisions on different criteria but the semantics of the 147 security attribute remain the same. The semantics required by the 148 security attributes are listed below: 150 o Must provide flexibility with respect to MAC model. 152 o Must provide the ability to atomically set security information 153 upon object creation 155 o Must provide the ability to enforce access control decisions both 156 on the client and the server 158 o Must not expose an object to either the client or server name 159 space before its security information has been bound to it. 161 NFSv4 provides several options for implementing the security 162 attribute. The first option is to implement the security attribute 163 as a named attribute. Named attributes provide flexibility since 164 they are treated as an opaque field but lack a way to atomically set 165 the attribute on creation. In addition, named attributes themselves 166 are file system objects which need to be assigned a security 167 attribute. This raises the question of how to assign security 168 attributes to the file and directories used to hold the security 169 attribute for the file in question. The inability to atomically 170 assign the security attribute on file creation and the necessity to 171 assign security attributes to its subcomponents makes named 172 attributes unacceptable as a method for storing security attributes. 174 The second option is to implement the security attribute as a 175 recommended attribute as defined in section 5.2 of RFC 3530. 176 Recommended attributes have a fixed format and semantics, which 177 conflicts with the flexible nature of the security attribute. To 178 resolve this the security attribute consists of two components. The 179 first component is a DOI to allow for interoperability between MAC 180 mechanisms. The second component is an opaque field which the actual 181 security attribute data. To allow for various MAC models NFSv4 182 should be used solely as a transport mechanism for the security 183 attribute. It is the responsibility of the endpoints to consume the 184 security attribute and make access decisions based on their 185 respective models. In addition, creation of objects through OPEN and 186 CREATE allows for the security attribute to be specified upon 187 creation. By providing an atomic create and set operation for the 188 security attribute it is possible to enforce the second and fourth 189 requirements. To this end the attribute number 76 is requested for 190 the security_attribute recommended attribute. 192 3.1. Interpreting security_attribute 194 The security_attribute field contains two components the first 195 component being a Domain of Interpretation(DOI). A DOI serves to 196 provide the receiving end with the information necessary to translate 197 the security attribute into a form that is usable by the endpoint. 198 The translation used to interpret the security attribute is not 199 specified as part of the protocol since it can depend on various 200 factors. The second component is an opaque section which contains 201 the data of the attribute. This component is dependent on the MAC 202 model to interpret and enforce. 204 3.2. Delegations 206 In the event that a security attribute is changed while a client 207 holds a delegation on the file, the client should follow the existing 208 protocol with respect to attribute changes. It should flush all 209 changes back to the server and relinquish the delegation. 211 3.3. Permission Checking 213 It is not feasible to enumerate all possible MAC models and even 214 levels of protection within a subset of these models. This means 215 that the NFSv4 client and servers can not be expected to directly 216 make access control decisions based on the security attribute. 217 Instead NFSv4 should defer permission checking on this attribute to 218 the host system. These checks are performed in addition to existing 219 DAC and ACL checks outlined in the NFSv4 protocol. Section 4 gives a 220 specific example of how the security attribute is handled under a 221 particular MAC model. 223 3.4. Object Creation 225 When creating files in NFSv4 the OPEN and CREATE operations are used. 226 One of the parameters to these operations is an fattr4 structure 227 containing the attributes the file is to be created with. This 228 allows NFSv4 to atomically set the security attribute of files upon 229 creation. When a client is MAC aware it must always provide the 230 initial security attribute upon file creation. In the event that the 231 server is the only MAC aware entity in the system it should ignore 232 the security attribute specified by the client and instead make the 233 determination itself. A more in depth explanation can be found in 234 Section 4. 236 4. MAC Security NFS Modes of Operation 238 A system using Labeled NFS may operate in three modes. The first 239 mode provides the most protection and is called "full" mode. In this 240 mode both the client and server implement a MAC model allowing each 241 end to make an access control decision. The remaining two modes are 242 variations on each other and are called "smart client" and "smart 243 server" modes. In these modes one end of the connection is not 244 implementing a MAC model and because of this these operating modes 245 offer less protection than full mode. 247 4.1. Full Mode 249 Full mode environments consist of MAC aware NFSv4 servers and clients 250 and may be composed of mixed MAC models and policies. The system 251 requires that both the client and server have an opportunity to 252 perform an access control check based on all relevant information 253 within the network. The file object security attribute is provided 254 using the mechanism described in Section 3. The security attribute 255 of the subject making the request is transported at the RPC layer 256 using the mechanism described in XXX: Insert RFC for RPC layer label 257 draft. 259 4.1.1. Initial Labeling and Translation 261 The ability to create a file is an action that a MAC model may wish 262 to mediate. The client is given the responsibility to determine the 263 initial security attribute to be placed on a file. This allows the 264 client to make a decision as to the acceptable security attributes to 265 create a file with before sending the request to the server. Once 266 the server receives the creation request from the client it may 267 choose to evaluate if the security attribute is acceptable. 269 Security attributes on the client and server may vary based on MAC 270 model and policy. To handle this the security attribute field has a 271 DOI component. This component is a mechanism for the host to 272 identify the meaning of the opaque portion of the security attribute. 273 A full mode environment may contain hosts operating in several 274 different DOIs. In this case a mechanism for translating the opaque 275 portion of the security attribute is needed. The actual translation 276 function will vary based on MAC model and policy and is out of the 277 scope of this document. If a translation is unavailable for a given 278 DOI then the request SHOULD be denied. Another recource is to allow 279 the host to provide a fallback mapping for unknown security 280 attributes. 282 4.1.2. Policy Enforcement 284 In full mode access control decisions are made by both the clients 285 and servers. When a client makes a request it takes the security 286 attribute from the requesting process and makes an access control 287 decision based on that attribute and the security attribute of the 288 object it is trying to access. If the client denies that access an 289 RPC call to the server is never made. If however the access is 290 allowed the client will make a call to the NFS server. 292 When the server receives the request from the client it extracts the 293 security attribute conveyed in the RPC request. The server then uses 294 this security attribute and the attribute of the object the client is 295 trying to access to make an access control decision. If the server's 296 policy allows this access it will fulfill the client's request, 297 otherwise it will return NFS4ERR_ACCESS 299 Implementations MAY validate security attributes supplied over the 300 network to ensure that they are within a set of attributes permitted 301 from a specific peer, and if not, reject them. Note that a system 302 may permit a different set of attributes to be accepted from each 303 peer. An example of this can be seen in Section 5.1.1. 305 4.2. Smart Client Mode 307 Smart client environments consist of NFSv4 servers are not MAC aware 308 but NFSv4 clients that are. All of the clients in this environment 309 are assumed to be implementing the same MAC model and will be running 310 the same policy. The system requires that all clients in the 311 environment be responsible for access control checks. Due to the 312 amount of trust placed in the clients this mode is only to be used in 313 a trusted environment. 315 4.2.1. Initial Labeling and Translation 317 Just like in full mode the client is responsible for determining the 318 initial label upon object creation. The server in smart client mode 319 does not implement a MAC model, however, it may provide the ability 320 to restrict the creation and labeling of object with certain labels 321 based on different criteria as described in Section 4.1.2. 323 In a smart client environment all of the clients operate in the same 324 DOI. This removes the need for the clients to maintain a set of DOI 325 translations. In order to support multiple DOIs in the same 326 environment it was considered that the DOI of the creating process 327 should be stored with the security attribute on the server. This was 328 abandoned due to the number of required DOI translations. In 329 practice all clients in this type of environment operate in the same 330 DOI. 332 4.2.2. Policy Enforcement 334 In smart client mode access control decisions are made by the 335 clients. When a client accesses an object it obtains the security 336 attribute of the object from the server and combines it with the 337 security attribute of the process making the request to make an 338 access control decision. This check is in addition to the DAC checks 339 provided by NFSv4 so this may fail based on the DAC criteria even if 340 the MAC policy grants access. As the policy check is located on the 341 client an access control denial should take the form that is native 342 to the platform. 344 4.3. Smart Server Mode 346 Smart server environments consist of NFSv4 servers that are MAC aware 347 and one or more MAC unaware clients. The server is the only entity 348 enforcing policy, and may selectively provide standard NFS services 349 to clients based on their authentication credentials and/or 350 associated network attributes (e.g. IP address, network interface). 351 The level of trust and access extended to a client in this mode is 352 configuration-specific. 354 4.3.1. Initial Labeling and Translation 356 In smart server mode all labeling and access control decisions are 357 performed by the NFSv4 server. In this environment the NFSv4 clients 358 are not MAC aware so they can not provide input into the access 359 control decision. This requires the server to determine the initial 360 labeling of objects. Normally the subject to use in this calculation 361 would originate from the client. Instead the NFSv4 server may choose 362 to assign the subject security attribute based on their 363 authentication credentials and/or associated network attributes (e.g. 364 IP address, network interface). 366 In smart server mode security attributes are contained solely within 367 the NFSv4 server. This means that all security attributes used in 368 the system remain within a single DOI. Since security attributes 369 will not cross DOIs there is no need to provide any translation 370 functionality above that which is needed internally by the MAC model. 372 4.3.2. Policy Enforcement 374 All access control decisions in smart server mode are made by the 375 server. The server will assign the subject a security attribute 376 based on some criteria (e.g. IP address, network interface). Using 377 the newly calculated security attribute and the security attribute of 378 the object being requested the MAC model makes the access control 379 check and returns NFS4ERR_ACCESS on a denial and NFS4_OK on success. 380 This check is done transparently to the client so if the MAC 381 permission check fails the client may be unaware of the reason for 382 the permission failure. When operating in this mode administrators 383 attempting to debug permission failures should be aware to check the 384 MAC policy running on the server in addition to the DAC settings. 386 5. Examples 388 The section below outlines an example of the Labeled NFS operation 389 modes using a traditional Multi Level Security(MLS) model where 390 objects are given a sensitivity level (Unclassified, Secret, Top 391 Secret etc..) and a category set. This is just one example of a 392 possible MAC model and is not required by labeled NFS 393 implementations. 395 5.1. Multi-Level Security 397 In a Multi-level security (MLS) system objects are generally assigned 398 a sensitivity level, and a set of compartments. The sensitivity 399 levels within the system are given an order ranging from lowest to 400 highest classification level. Read access to an object is allowed 401 when the sensitivity level of the subject "dominates" the object it 402 wants to access. This means that the sensitivity level of the 403 subject is higher than that of the object it wishes to access and 404 that its set of compartments is a super-set of the compartments on 405 the object. 407 The rest of the section will just use sensitivity levels. In general 408 the example is a client that wishes to list the contents of a 409 directory. The system defines the sensitivity levels 410 Unclassified(U), Secret(S), and Top Secret(TS). The directory to be 411 searched is labeled Top Secret which means access to read the 412 directory will only be granted if the subject making the request is 413 also labeled Top Secret. 415 5.1.1. Full Mode 417 In the first part of this example a process on the client is running 418 at the Secret level. The process issues a readdir system call which 419 enters the kernel. Before translating the readdir system call into a 420 request to the NFSv4 server the host operating system will consult 421 the MAC module to see if the operation is allowed. Since the process 422 is operating at Secret and the directory to be accessed is labeled 423 Top Secret the MAC module will deny the request and an error code is 424 returned to user space. 426 Consider a second case where instead of running at Secret the process 427 is running at Top Secret. In this case the sensitivity of the 428 process is equal to or greater than that of the directory so the MAC 429 module will allow the request. Now the readdir is translated into 430 the necessary NFSv4 call to the server. For the RPC request the 431 client is using the proper credential to assert to the server that 432 the process is running at Top Secret. 434 When the server receives the request it extracts the security label 435 from the RPC session and retrieves the label on the directory. The 436 server then checks with its MAC module if a Top Secret process is 437 allowed to read the contents of the Top Secret directory. Since this 438 is allowed by the policy then the server will return the appropriate 439 information back to the client. 441 In this example the policy on the client and server were both the 442 same. In the event that they were running different policies a 443 translation of the labels might be needed. In this case it could be 444 possible for a check to pass on the client and fail on the server. 445 The server may consider additional information when making its policy 446 decisions. For example the server could determine that a certain 447 subnet is only cleared for data up to Secret classification. If that 448 constraint was in place for the example above the client would still 449 succeed, but the server would fail since the client is asserting a 450 label that it is not able to use (Top Secret on a Secret network). 452 5.1.2. Smart Client Mode 454 In smart client mode the example is identical to the first part of a 455 full mode operation. A process on the client labeled Secret wishes 456 to access a Top Secret directory. As in the full mode example this 457 is denied since Secret does not dominate Top Secret. If the process 458 were operating at Top Secret it would pass the local access control 459 check and the NFSv4 operation would proceed as in a normal NFSv4 460 environment. 462 5.1.3. Smart Server Mode 464 In a smart server mode the client behaves as if it were in a normal 465 NFSv4 environment. Since the process on the client does not provide 466 a security attribute the server must define a mechanism for labeling 467 all requests from a client. Assume that the server is using the same 468 criteria used in the full mode example. The server sees the request 469 as coming from a subnet that is a Secret network. The server 470 determines that all clients on that subnet will have their requests 471 labeled with Secret. Since the directory on the server is labeled 472 Top Secret and Secret does not dominate Top Secret the server would 473 fail the request with NFS4ERR_ACCESS. 475 6. Security Considerations 477 Depending on the level of protection the MAC system offers there may 478 be a requirement to tightly bind the security attribute to the data. 479 It must be taken into consideration that when used in a pNFS 480 environment is it possible that the security attribute and file data 481 will be stored on separate servers. 483 7. IANA Considerations 485 It is requested that IANA creates a registry of Domain of 486 Interpretation numbers to be consumed by a Domain of Interpretation 487 authority which will provide the mappings. 489 XXX: This section should probably be replaced with the section from 490 the CALIPSO document on DOIs. If we agree on that format we could 491 draw up an RFC for it and say that they should be managed by IANA as 492 specified in rfc****. 494 8. Normative References 496 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 497 Requirement Levels", March 1997. 499 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 500 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 501 October 1998. 503 Authors' Addresses 505 David P. Quigley 506 National Security Agency 507 9800 Savage Rd. 508 Suite 6534 509 Ft. Meade, MD 20755-6534 511 Email: dpquigl@tycho.nsa.gov 513 James Morris 514 Red Hat, Inc. 516 Email: jmorris@namei.org