CMSC 414 Computer (and Network) Security Lecture 13

1. CMSC 414Computer (and Network) SecurityLecture 13 Jonathan Katz

2. Midterm? • Will be held Oct 21, in class • Will cover everything up to and including the preceding lecture (Oct 16) • Includes all reading posted on the class syllabus!

3. Access control lists (ACLs) • Instead of storing central matrix, store each column with the object it represents • Stored as pairs (s, r) • Subjects not in list have no rights • Can use wildcards to give default rights

4. Example: Unix • Unix divides users into three classes: • Owner of the file • Group owner of the file • All other users • Note that this leaves little flexibility… • Some systems have been extended to allow for more flexibility • Abbrev. ACLs overridden by explicit ACLs

5. Handling conflicts • Conflicts may arise if two entries give different permissions to a subject • Multiple ways of resolving this; e.g.: • Allow access if any entry gives rights • Allow access only if no entry denies rights • Apply first applicable entry

6. Default permissions? • Two approaches • Apply ACL entry, if it exists; otherwise, apply default rule • I.e., ACL entries override default permissions • Augment the default permissions with those in the appropriate ACL entry • Example: what if default allows “read” and ACL entry states “write”?

7. Revocation • How to handle revocation? • Easy to revoke all access with ACLs • But…what if two different users granted the same right to the same person? • E.g., both A and B give rights to C. Now A wants to revoke C’s rights. But B still wants to allow rights… • Can store a history of ACL modifications

8. Example: Windows NT • Rights: • Read; write; execute; delete; own • Generic (groups of) rights: • No access; read; change; full • Also, a “special access” right (allows any combination of rights)

9. Example, continued… • When user accesses a file • If user not present in ACL, nor member of any group in ACL, deny access • If user (or group containing user) is explicitly denied access in ACL, deny access • Else, user has union of all rights from each ACL entry for user (or group containing user)

10. Example, continued… • Paul, Quentin are in group “students” • Quentin, Regina are in group “staff” • File with ACL: (staff, full), (Quentin, change), (students, no access), (Paul, no access) • Regina has full access • Quentin has no access (since in “students”) • Paul has no access • Note: an explicit deny overrides any permissions • Safer to explicitly disallow access when unwanted • E.g., in case “students” is later allowed access

11. Capabilities • The “dual” of ACLs • The row of an access control matrix is associated with the corresponding subject • More complex to implement securely than ACLs • A process must identify a capability… • …so must have some control over it • (In contrast, the OS controls files)

12. Protecting capabilities • Can “tag” capabilities so they can be read, but not modified, by processes • Or, store capabilities in protected memory • Can also use cryptography to ensure integrity of capabilities • Using a message authentication code, with a key known to the OS

13. Copying capabilities • Copying a capabilities implies giving rights • Copy flag is associated with capabilities • Process cannot copy the capability unless this flag is set

14. Revocation • How to revoke access to a file? • Would potentially require revoking all capabilities associated with that file • One solution: indirection • Capabilities name an entry in a table, rather than an object itself • To revoke access to object, invalidate entry in table • Or, change random number associated with object • Difficult to revoke access by a single subject

15. Potential problems • What if one process gives capabilities to another? (Possibly indirectly) • Can lead to security violation • One solution: assign security classifications to capabilities • E.g., when capability created, its classification is the same as the requesting process • Capability contains rights depending on the object to which it refers

16. ACLs vs. capabilities • Given a subject, what objects can it access? (capabilities) • Given an object, which subjects can access it? (ACLs) • Second question is asked more often than first • For incident response, capabilities may be preferable • “What else did this subject access?”

17. “Locks and keys” • Combines ACLs and capabilities • “Lock” associated with each object • “Key” associated with each subject authorized to access this object • When subject tries to access object, its set of keys is checked; if it has a key corresponding to the object’s lock, access allowed

18. Important distinction • ACLs and capabilities are “static” • Require manual intervention to change • Locks and keys are “dynamic” • May change on their own in response to changes in the system

19. Example • Cryptographic key used to encrypt a file • A file cannot be “read” unless the subject has the encryption key • Can also enforce that requests from n users are required in order to read data (and-access), or that any of n users are able to read data (or-access)

20. Cryptographic secret sharing • (t, n)-threshold scheme to share a “key” • Using this to achieve (t, n)-threshold encryption • Shamir secret sharing

21. Another example • Type checking • E.g., label memory locations as either “data” or “instructions” • Do not allow execution of type “data” • Can potentially be used to limit buffer overflows

22. Ring-based access control • Memory and files (e.g., disk space) are viewed as equivalent • E.g., a program is loaded into memory and run, or a file is loaded into RAM • Termed “segments” • Two types of segments: data and procedure • ACLs specify rights on per-user basis • All procedures executed by a user have rights associated with that user

23. Ring-based access control • Sequence of 64 “protection rings” • Kernel in ring 0 • Higher ring numbers have lower privileges • Proc. in ring r wants to access data segment • Data associated with access bracket (a, b) • If r  a, access allowed • If r > b, no access • Else, read allowed; write denied

24. Ring-based access control • Procedure in ring r wants to execute another procedure segment • Procedure segment has access bracket (a, b), and also has call bracket (b, c) • If r < a, access permitted but “ring fault” occurs and trap to kernel • If r lies between a and b, all access permitted • If r lies between b and c, access permitted via “gate” • If r > c, all access denied

25. Why brackets? • In theory, a process or file should be assigned to one ring • However, this would require a call to the OS every time a process from another ring needed access; access bracket fixes this problem • Call bracket allows user to execute programs in well-defined ways (i.e., via gates)

26. Propagated ACLs • Associated with data, not the object holding the data • Prevents one user from copying data in a file to a new file, thereby giving access to the data • When a subject reads from an object, the subject’s PACL is updated • When an object is created, the object takes on the PACL of the creator

27. Example… • A creates file f, and allows B, D to access it • After B reads f, PACLnew(B) = PACLold(B)  PACL(A) • If B creates new file f’, this file is assigned PACLnew(B) • User U can access f’ only if U is in both PACLold(B) and PACL(A)