idnits 2.17.1 draft-deason-afs3-acl-restrictions-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 == Line 287 has weird spacing: '...anyuser rl...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (January 13, 2010) is 5217 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 N/A A. Deason 3 Internet-Draft M. Meffie 4 Intended status: Experimental T. Keiser 5 Expires: July 17, 2010 Sine Nomine 6 January 13, 2010 8 Methods of Specifying Restrictions on AFS3 ACLs 9 draft-deason-afs3-acl-restrictions-01 11 Abstract 13 The AFS-3 ACL 'a' bit gives users unfettered power to grant, or 14 revoke, privileges, with no provision for enforcing site policy. 15 This memo provides several alternative mechanisms for creating 16 restrictions on what powers the 'a' bit denotes. Three alternative 17 mechanisms for restricting the power of the 'a' bit are proposed: a 18 method for overlaying the ACL with a site-controlled ACL; a method 19 for masking the ACL with a site-controlled privilege mask; and a 20 finely granular meta-acl mechanism for restricting to whom privileges 21 may be delegated, and which privileges may be given to different 22 classes of principals. This memo will serve as a basis for the ACL 23 restriction discussion with the AFS-3 protocol working group. The 24 intended goal of this discussion is to reach consensus on 25 standardization of one or more solutions, and then publish a BCP 26 status memo. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 This Internet-Draft will expire on July 17, 2010. 51 Copyright Notice 53 Copyright (c) 2010 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the BSD License. 66 1. Introduction 68 Currently sites may give users administrative rights on certain 69 directories in AFS, such as home directories and shared project 70 directories. Users should not, but can, give overly permissive ACLs 71 to those directories. For example, a user could give write and even 72 admin permissions to the system:anyuser group ('fs sa $HOME system: 73 anyuser rlidwka'). 75 This can which can lead to problematic situations, especially for 76 directories that can be served over http. As it stands today, the 77 only possible way for AFS administrators to prevent this (at least in 78 OpenAFS) is to monitor the fileserver's audit log, and correct ACLs 79 that are overly permissive. But this is suboptimal, and is an after- 80 the-fact check. 82 If you see a viable solution to this problem not listed here, or see 83 any problems with our methods, please let us know. Or if a solution 84 to this problem is valuable to you or your organization, also please 85 let us know. 87 1.1. Requirements Language 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in RFC 2119 [RFC2119]. 93 2. Proposed solutions 95 Discussions have shown that preventing this is not a simple issue, 96 and that there are a few ways to go about it, each with advantages 97 and disadvantages. Here we will outline 3 general approaches, and 98 show how to use them to meet certain illustrative use cases. 100 Since the rest of this is quite long, here's a quick summary of the 101 conclusions. We have three methods: 'method A' is the "volume-level 102 ACL overlays" idea, 'method B' is the "volume ACL masks" idea, and 103 'method C' is the "volume ACL policies" idea. While none of these in 104 themselves cover all corners of all possible use cases, we would 105 probably implement either C by itself, or A and B together to cover a 106 large enough majority of use cases. Of course, unless a serious 107 problem is found, there is no reason to not implement all three. 109 The bottom line is that I find method C to be the most flexible and 110 the least confusing to end-users, but it is the most confusing to 111 administrators, and it is the slowest (when changing the volume-level 112 permissions). Using methods A+B has the opposite pros/cons. 114 Here are the details. Each method has an explanation for what it 115 generally is and how it works, followed by its use in a few simple 116 use-case scenarios, followed by the pros/cons. 118 2.1. Method A: volume-level ACL overlays 120 With this method, we maintain a single additional ACL in the volume 121 metadata, which is applied to access checks in the volume after 122 performing the per-directory ACL check. It can be thought of as 123 similar to the OpenAFS fileserver's -implicit flag, but more 124 generalized. 126 For example, if we wanted a volume where system:backups was 127 guaranteed to have 'rl' rights, and system:evilusers was guaranteed 128 to not have _any_ rights, the volume-level ACL overlay would look 129 like this: 131 positive: 132 system:backups rl 133 negative: 134 system:evilusers rlidwka 136 Thus, any time an access check is done on an ACL anywhere in the 137 volume: after we do the normal directory ACL check, we look at this 138 volume-level ACL. If the accessing user is in system:backups, they 139 will get rl rights, and if they are in system:evilusers, all of their 140 rights will go away. 142 2.1.1. How do I prevent system:anyuser/system:authuser write access? 144 To prevent system:anyuser from having write access, we will need to 145 allow specifying the 'anonymous' user in the volume-level ACL, which 146 refers only to unauthenticated accesses. Then, you just give 147 negative write rights to the anonymous user. The command would look 148 something like: 150 vos setacl -vol user.adeason -acl anonymous idwka -neg 152 For system:authuser, you cannot prevent write access with this 153 method. It is a limitation of this approach. (Giving system: 154 authuser negative idwka rights would revoke those rights from _all_ 155 authenticated users, which is probably not what you want to do.) 157 2.1.2. How do I ensure nobody in group.foo gets write access? 159 Just grant negative idwka access to group.foo on the volume. 160 Something like: 162 vos setacl -vol user.adeason -acl group.foo idwka -neg 164 Members of group.foo will now not be able to write anything in the 165 volume. 167 2.1.3. How do I guarantee group.bar read access? 169 Same as above, just grant positive read rights. Something like: 171 vos setacl -vol user.adeason -acl group.bar rl 173 2.1.4. Method A advantages 175 o Changing the volume-level rights is quick. 177 o Minimal end-administrator confusion; this is relatively simple to 178 understand. 180 o Simpler than method C to implement. 182 2.1.5. Method A disadvantages 184 o We have no way to restrict access of special groups like system: 185 authuser or host IP groups. To get this, we'd have to combine 186 with method with method B or C. 188 o There is no way to override the volume-level ACL, and have an 189 administrator force e.g. system:anyuser write access on a 190 particular directory. 192 o Higher end-user confusion. With legacy 'fs listacl', there is no 193 way to see that there is a volume-level ACL in play, and users may 194 have no idea why access is failing for certain cases. Of course, 195 releasing new tools can fix that. 197 o Performance impact is an extra O(n) ACL calculation for the 198 volume-level ACL overlay in the critical path. But those ACLs 199 should be small anyway. 201 2.2. Method B: volume ACL masks 203 With this method, we maintain a mapping of users to a rights mask. 204 Any time an ACL access check is performed, if a positive ACL entry 205 matches a user in that table, the acquires rights are masked to the 206 rights mask in the table. 208 For example, if we wanted to prevent users from giving away write 209 access to system:anyuser, and prevent users from giving admin access 210 to system:authuser, we could have a table like so: 212 system:anyuser rl 213 system:authuser rlidwk 215 So any time an ACL entry for system:anyuser appears, everything is 216 treated as if the rights in that ACL entry were logically ANDed with 217 'rl'. So no user can gain more than 'rl' rights on a directory 218 simply by being in system:anyuser. 220 2.2.1. How do I prevent system:anyuser/system:authuser write access? 222 Set the rights mask for them to just 'rl'. Something like: 224 vos setaclmask -vol user.adeason -user system:anyuser -mask rl 226 So any time an ACL entry for system:anyuser appears in the volume, 227 everything will act as if the rights were limited to rl. 229 2.2.2. How do I ensure nobody in group.foo gets write access? 231 You cannot _prevent_ access for an arbitrary group with this method, 232 but you can make it harder to do accidentally. You can set the 233 rights mask like so: 235 vos setaclmask -vol user.adeason -user group.foo -mask rl 237 Which restricts any rights for group.foo on any ACL to be restricted 238 to 'rl'. However, a user can intentionally work around this by 239 simply placing group.foo in another group: 241 pts creategroup adeason:foo 242 pts adduser group.foo adeason:foo 243 fs setacl $DIR adeason:foo rlidwka 245 Since group.foo itself never apears in the ACL, the ACL mask is 246 bypassed. 248 2.2.3. How do I guarantee group.bar read access? 250 You cannot. This method cannot grant additional rights. 252 2.2.4. Method B advantages 254 o Changing the rights mask is quick. 256 o Runtime performance overhead in the critical path is O(1). 258 2.2.5. Method B disadvantages 260 o Not as useful for non-'special' groups. That is, it can be 261 trivially worked around, unless you only use this for groups like 262 system:anyuser, system:authuser, or host IP groups. 264 o No way to override the ACL masks on a particular directory, if the 265 administrator wants to. 267 o Higher end-user confusion with legacy client tools. There's no 268 way to see what the ACL rights are restricted to until newer 269 client tools are deployed. 271 2.3. Method C: volume ACL policies 273 With this method, we maintain policies of who is allowed to set what 274 ACLs in a volume. That is, unlike methods A and B, we perform 275 additional access checks at SetACL time, not at the time when the 276 files are accessed. We would have 4 volume-level ACLs that define 277 what users are allowed to add positive rights ('add-positive'), 278 remove positive rights ('remove-positive'), add negative rights 279 ('add-negative'), and remove negative rights ('remove-negative'). 281 For example, to allow nobody but system:powerusers to grant idwka 282 rights to system:anyuser, we'd have a policy for system:anyuser that 283 would look like this: 285 add-positive: 286 system:powerusers rlidwka 287 system:anyuser rl 289 After that policy is set, any time a user not in system:powerusers 290 tries to grant system:anyuser more than rl rights, they will get an 291 EACCES error. This does not change the existing ACLs in the volume; 292 an administrator will need to run an auditing tool to make sure that 293 existing ACLs comply with the volume policy. 295 2.3.1. How do I prevent system:anyuser/system:authuser write access? 297 You would call something like this 299 vos setpolicy -add-positive \ 300 -user system:anyuser \ 301 -set-rights rl \ 302 -for-user system:anyuser \ 303 -in-volume user.adeason 305 to prevent people from giving system:anyuser write access. To ensure 306 that existing ACLs don't permit write access, you would need to run 307 something like 309 vos auditpolicy -vol user.adeason 311 2.3.2. How do I ensure nobody in group.foo gets write access? 313 To prevent an arbitrary normal group from getting write access, 314 things are slightly different. You would need to prevent users from 315 taking away negative idwka rights, and then assign negative idwka 316 rights to all directories in the volume. So, something like 318 vos setpolicy -remove-negative \ 319 -user system:anyuser \ 320 -set-rights rl \ 321 -for-user group.foo \ 322 -in-volume user.adeason 324 Would allow users to only remove 'rl' rights from group.foo in 325 negative ACLs. Then you would need to set negative idwka ACLs on all 326 directories in the volume. 328 2.3.3. How do I guarantee group.bar read access? 330 Prevent normal users from taking away read access from group.bar, and 331 from granting negative read access for group.bar: 333 vos setpolicy -remove-positive \ 334 -user system:anyuser \ 335 -set-rights idwka \ 336 -for-user group.bar \ 337 -in-volume user.adeason 339 vos setpolicy -add-negative \ 340 -user system:anyuser \ 341 -set-rights idwka \ 342 -for-user group.bar \ 343 -in-volume user.adeason 345 Then, grant read access for group.bar in all directories in the 346 volume. 348 2.3.4. Method C advantages 350 o More flexible for a variety of situations. In particular, this 351 allows administrators (or an arbitrary administrator-defined set 352 of users) to override the volume policies, and set e.g. system: 353 anyuser write on a particular directory if they so wish. 355 o No performance overhead at access-check time. All of the 356 additional access checks are done during SetACL. 358 o Minimal end-user confusion. ACLs accurately represent exactly 359 what rights different users have. Trying to set an ACL that 360 violates the policy will result in EACCES, so they know the SetACL 361 operation didn't work. It may be confusing as to why it did not, 362 but at least it is clear that the ACL was not changed. 364 2.3.5. Method C disadvantages 366 o Volumes need to be 'audited' (or all of the ACLs just need to be 367 set) to make sure they comply with the ACL policy, which can be 368 very slow. 370 o Higher end-administrator confusion. This by far the most 371 confusing method for administrators to set ACL policies. 373 3. Summary 375 As I mentioned, we could just do all of these, since they are 376 potentially best suited to different scenarios. Either method C by 377 itself or methods A and B together do seem to cover most of the 378 immediately-apparent use cases, though. To summarize the general 379 areas in which the different methods are better or worse: 381 Better | Worse 382 --------------------- 383 flexibility: : method C | method A+B 384 end-user confusion : method C | method A+B 385 end-admin confusion: method A+B | method C 386 policy-change speed: method A+B | method C 388 There are other pros and cons, but I think those areas are the only 389 ones where it matters much. If you see any problems that aren't 390 listed here, or if you particularly want one of the described 391 methods, please let us know. 393 4. Acknowledgements 395 The authors would like to thank Jim Rowan for discussing problematic 396 interactions between the proposed ACL policy management techniques 397 and PTS user-managed groups, and Jeffrey Altman for helping to better 398 frame the problem statement and proposing alternative 399 implementations. 401 5. IANA Considerations 403 This memo includes no request to IANA. 405 6. Security Considerations 407 The existing security model is known to be flawed. This draft 408 attempts to improve the situation by limiting the extent to which end 409 users can modify file system permissions. However, it is known that 410 this is not sufficient to address all possible ACL attack vectors. 411 Two key areas of concern are authorization for modification of policy 412 metadata, and interaction with user-managed PTS groups. 414 How modification of policy data will be authorized in an environment 415 using RBAC is not clear; it is known that system:administrators is 416 not always the appropriate group of principals. In highly secured 417 environments there may be a desire to restrict modification of policy 418 to a security-related group, rather than the group responsible for 419 maintaining the AFS server plant. This is not addressed in the memo, 420 although it could be addressed by means of additional per-volume 421 metadata. 423 There are proposed attack vectors by which a user-managed group can 424 be used to get around ACL restrictions. While these attacks can 425 bypass a naive ACL policy specification, it is possible to circumvent 426 these techniques through the use of negative access control policy 427 entries. 429 7. Normative References 431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 432 Requirement Levels", BCP 14, RFC 2119, March 1997. 434 Authors' Addresses 436 Andrew Deason 437 Sine Nomine Associates 438 43596 Blacksmith Square 439 Ashburn, Virginia 20147-4606 440 USA 442 Phone: +1 703 723 6673 443 Email: adeason@sinenomine.net 445 Michael Meffie 446 Sine Nomine Associates 447 43596 Blacksmith Square 448 Ashburn, Virginia 20147-4606 449 USA 451 Phone: +1 703 723 6673 452 Email: mmeffie@sinenomine.net 454 Thomas Keiser 455 Sine Nomine Associates 456 43596 Blacksmith Square 457 Ashburn, Virginia 20147-4606 458 USA 460 Phone: +1 703 723 6673 461 Email: tkeiser@sinenomine.net