CIT 380: Securing Computer Systems

1. CIT 380: Securing Computer Systems Access Control CIT 380: Securing Computer Systems

2. Access Control Matrix • As system changes, state changes. • State transitions. • Only concerned with protection state. • ACM must be enforced by a mechanism that limits state transitions to those that go from one element of Q to another. CIT 380: Securing Computer Systems

3. Objects O = { o1,…,om } All protected entities. Subjects S = { s1,…,sn } Active entities, S  O Rights R = { r1,…,rk } Entries A[si, oj] R A[si, oj] = { rx, …, ry } means subject si has rights rx, …, ry over object oj objects (entities) o1 … oms1 … sn s1 s2 … sn subjects Access Control Matrix CIT 380: Securing Computer Systems

4. Access Control Matrix • Subjects • Users • Processes (Programs) • Objects • Processes (Programs) • Files CIT 380: Securing Computer Systems

5. Access Control Matrix • Rights • Read (r) • Write (w) • Execute (x) • Append (a) • Owner (o) • Copy Rights (c) CIT 380: Securing Computer Systems

6. Example: File/Process • Processes p, q • Files f, g • Rights r, w, x, a, o f g p q p rwo r rwxo w q a ro r rwxo CIT 380: Securing Computer Systems

7. Copy Right • Allows possessor to give rights to another • Often attached to a right, so only applies to that right • r is read right that cannot be copied • rc is read right that can be copied • Is copy flag copied when giving r rights? • Depends on model, instantiation of model CIT 380: Securing Computer Systems

8. Ownership Right Usually allows possessor to change entries in ACM column • So owner of object can add, delete rights for others • May depend on what system allows • Can’t give rights to specific (set of) users • Can’t pass copy flag to specific (set of) users CIT 380: Securing Computer Systems

9. Attenuation of Privilege Principle: Subject may not give rights it does not possess to another. • Restricts addition of rights within a system • Usually ignored for owner • Why? Owner gives herself rights, gives them to others, deletes her rights. CIT 380: Securing Computer Systems

10. How can we implement the ACM? Problem: scale • Thousands of subjects. • Millions of objects. • Yet most entries are blank or default. Solutions • Group subjects together as a single entities • Groups and Roles • Implement by row: Capabilities • Implement by column: Access Control Lists CIT 380: Securing Computer Systems

11. Groups and Roles • Collect subjects together to express: • Need to share objects. • Security categories (e.g., admin, faculty, student, guest) • role: group that ties membership to function • Problem: loss of granularity. CIT 380: Securing Computer Systems

12. Capabilities • Implement ACM by row. • Access Control associated with subject. • Example: UNIX file descriptors • System checks ACL on file open, returns fd. • Process subsequently uses fd to read and write file. • If ACL changes, process still has access via fd. CIT 380: Securing Computer Systems

13. Capability Questions How to revoke rights to an object? • Direct solution • Check capabilities of every process. • Remove those that grant access to object. • Computationally expensive. CIT 380: Securing Computer Systems

14. Access Control Lists (ACLs) • Implement ACM by column. • Access control by object. • Example: UNIX ACLs • Short “rwx” user/group/other. • Long POSIX ACLs. CIT 380: Securing Computer Systems

15. ACL Questions • Which subjects can modify an object’s ACL? • Do ACLs apply to privileged users? • Do ACLs support groups and wildcards? • How are ACL conflicts resolved? • What are default permissions? • How can a subject’s rights be revoked? CIT 380: Securing Computer Systems

16. Which subjects can modify an ACL? • Create an own right for an ACL. • Only subjects with own right can modify ACL. • Creating an object also creates object’s ACL. • Usually creator given own right at this time. • Other default rights may be set at creation too. CIT 380: Securing Computer Systems

17. Which subjects can modify an ACL? • Some systems allow anyone with access to object to modify ACL. • What are the security implications of sharing access to a file on such a system? CIT 380: Securing Computer Systems

18. Do ACLs apply to privileged users? • Many systems have privileged users. • UNIX: root. • Windows NT: administrator. • Should ACLs apply to privileged users? • Need read access to all objects for backups. • What security problems are produced by ignoring ACLs for privileged users? CIT 380: Securing Computer Systems

19. What are the default permissions? • Interaction of ACLs with base permissions. • POSIX ACLs modify UNIX base permissions. CIT 380: Securing Computer Systems

20. What are the default permissions? • How are default ACLs determined? • Subject • Subject sets default permissions, like UNIX umask. • Inheritance • Objects in hierarchical system inherit ACLs of parent object. • Subjects inherit sets of default permissions from their parent subjects. CIT 380: Securing Computer Systems

21. How are rights revoked? Removal of subject’s rights to object. • Delete entries for subject from ACL. • If ownership doesn’t control granting rights, matters can be complex: • If A has granted rights to B, what should happen to B’s rights if you remove A’s rights? Removal of subject’s rights to all objects. • Very expensive (millions of objects.) • Most systems don’t support. • Why isn’t disabling subject’s account sufficient? CIT 380: Securing Computer Systems

22. ACLs vs Capabilities ACLs • Slow: OS has to read ACL for each object accessed. • Easy to find/change rights on a particular object. • Difficult to revoke privileges for a specific subject. • Capabilities • Fast: OS always knows subject identity. • Easy to find/change rights on a particular subject. • Difficult to revoke privileges to a subject object. CIT 380: Securing Computer Systems

23. Limitations of Classic ACLs ACL control list only contains 3 entries • Limited to one user. • Limited to one group. Root (UID 0) can do anything. CIT 380: Securing Computer Systems

24. POSIX Extended ACLs Supported by most UNIX/Linux systems. • Slight syntax differences may exist. getfacl setfacl • chmod 600 file • setfacl -m user:gdoor:r-- file • File unreadable by other, but ACL allows gdoor CIT 380: Securing Computer Systems

25. Host-based Access Control • /etc/hosts.allow and /etc/hosts.deny • used by tcpd, sshd, other servers • Identify subjects by • hostname • IP address • network address/mask • Allow before Deny • use last rule in /etc/hosts.deny to deny all CIT 380: Securing Computer Systems

26. Hardware Protection Confidentiality • Processes cannot read memory space of kernel or of other processes without permission. Integrity • Processes cannot write to memory space of kernel or of other processes without permission. CIT 380: Securing Computer Systems

27. Hardware Protection Availability • One process cannot deny access to CPU or other resources to kernel or other processes. CIT 380: Securing Computer Systems

28. Hardware Mechanisms: VM • Each process has its own address space. • Prevents processes from accessing memory of kernel or other processes. • Attempted violations produce page fault exceptions. CIT 380: Securing Computer Systems

29. Hardware Mechanisms: VM • Each process has its own address space. • Implemented using a page table. • Page table entries contain access control info. • Read • Write • Execute (not separate on Intel CPUs) • Supervisor (only accessible in supervisor mode) CIT 380: Securing Computer Systems

30. VM Address Translation CIT 380: Securing Computer Systems

31. Hardware Mechanisms: Rings Protection Rings. • Lower number rings have more rights. • Intel CPUs have 4 rings • Ring 0 is supervisor mode. • Ring 3 is user mode. • Most OSes do not use other rings. • Multics used 64 protection rings. • Different parts of OS ran in different rings. • Procedures of same program could have different access rights. CIT 380: Securing Computer Systems

32. Hardware Mechanisms: System Timer • Timer interrupt • Programmable Interval Timer chip. • Happens every 1-100 OS, depending on OS. • Transfers control from process to OS. • Ensures no process can deny availability of machine to kernel or other processes. CIT 380: Securing Computer Systems

33. Why is Access Control hard? • Complex Objects • Identifying objects of interest. • Is your choice of objects too coarse or fine-grained? • Hierarchical structure like filesystem or XML • Subjects are Complex • Identifying subjects of interest. • What are the relationships between subjects? CIT 380: Securing Computer Systems

34. Why is Access Control hard? • Access Control states change. • Security objectives often unclear. CIT 380: Securing Computer Systems

35. References • Anderson, Ross, Security Engineering, Wiley, 2001. • Bishop, Matt, Introduction to Computer Security, Addison-Wesley, 2005. • Bovet, Daniel and Cesati, Marco, Understanding the Linux Kernel, 2nd edition, O’Reilly, 2003. • Silberschatz, et. al., Database System Concepts, 4th edition, McGraw-Hill, 2002. • Silberschatz, et. al., Operating System Concepts, 7th edition, Wiley, 2005. • Viega, John, and McGraw, Gary, Building Secure Software, Addison-Wesley, 2002. CIT 380: Securing Computer Systems