CIT 380: Securing Computer Systems

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

2. UNIX Access Control Model • UID • integer user ID • UID=0 is root • GID • integer group ID • Users can belong to multiple groups CIT 380: Securing Computer Systems

3. UNIX File Permissions Three sets of permissions: • User owner • Group owner • Other (everyone else) Three permissions per group • read • write • execute • UID 0 can access regardless of permissions. • Files: directories, devices (disks, printers), IPC CIT 380: Securing Computer Systems

4. UNIX File Permissions Best-match policy • OS applies permission set that most closely matches. • You can be denied access by best match even if you match another set. Directories • read = listing of directory • execute = traversal of directory • write = add or remove files from directory CIT 380: Securing Computer Systems

5. Octal Permission Notation Each set (u,g,o) is represented by an octal digit. Each permission (r,w,x) is one bit within a digit. ex: chmod 0644 file u: rw, g: r, o: r ex: chmod 0711 bin u: rwx, g: x, o: x CIT 380: Securing Computer Systems

6. Changing Ownership newgrp • Group owner of files is your default group. • Changes default group to another group to which you belong. chgrp • Changes group owner of existing file. chmod • Changes owner of existing file. • Only root can use this command. CIT 380: Securing Computer Systems

7. Default Permissions: umask • Determines access permissions given to newly created files • Three-digit octal number • Programs default to 0666 • Umask modifies to: 0666 & ~umask • ex: umask=022 => file has mode 0644 • ex: umask=066 => file has mode 0600 CIT 380: Securing Computer Systems

8. Access Control • What is Access Control? • Access Control Matrix Model • Protection State Transitions • Special Rights • Principle of Attenuation of Privilege • Groups and Roles • Implementation of the Access Control Matrix • Access Control Lists: by column (object). • Capabilities: by row (subject). • UNIX • Hardware Protection CIT 380: Securing Computer Systems

9. Why study Access Control? • Center of gravity of computer security • Why do we authorize users? • What security features do OSes provide? • What’s the purpose of cryptography? • Access Control is pervasive. • Access Control is where Computer Science meets Security Engineering. • We’ll start with theory (computer science) • Then examine implementations (engineering) CIT 380: Securing Computer Systems

10. Access Control is Pervasive Application Middleware Operating System Hardware CIT 380: Securing Computer Systems

11. Access Control is Pervasive • Application • Complex, custom security policy. • Ex: Amazon account: wish list, reviews, purchases • Middleware • Database, system libraries, 3rd party software • Ex: Credit card authorization center • Operating System • File ACLs, account permissions • Hardware • Memory management, hardware device access. CIT 380: Securing Computer Systems

12. Access Control Matrix • Precisely describes protection state of system. P Q • Sets of system states: • P: Set of all possible states. • Q: Set of allowed states, according to security policy. • P-Q: Set of disallowed states. • ACM describes the set of states Q. CIT 380: Securing Computer Systems

13. 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

14. 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

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

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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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

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

31. 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

32. 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

33. 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

34. 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

35. 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

36. 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

37. 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

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

39. 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

40. 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

41. VM Address Translation CIT 380: Securing Computer Systems

42. 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

43. 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

44. 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

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

46. 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