CIT 380: Securing Computer Systems

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

2. 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, Windows NT, and SQL ACLs. • Hardware Protection CIT 380: Securing Computer Systems

3. Why study Access Control? • Center of gravity of computer security • Why do we authenticate 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

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

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

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

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

8. 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 ACM Description CIT 380: Securing Computer Systems

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

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

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

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

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

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

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

16. Capability Questions • How to prevent user from modifying capabilities? • How to prevent user from copying capabilities? • How to revoke rights to an object? CIT 380: Securing Computer Systems

17. How to prevent user from modifying? Memory protection • Capabilities are readable, but not writable. Indirection • Capability is pointer to per-process table whose access control prevents user from touching. Cryptography • Cryptographically secure checksum associated with capability and checked before usage. CIT 380: Securing Computer Systems

18. How to prevent user from copying? • Copying capabilities allows users to grant rights to others. • Solution: • Use indirection or cryptographic techniques from prev slide to prevent direct access. • Add copy flag to capability, as a specific right given to copy capabilities in order to give rights to other users. CIT 380: Securing Computer Systems

19. How to revoke rights to an object? • Direct solution • Check capabilities of every process. • Remove those that grant access to object. • Computationally expensive. • Alternative solution • Create a global object table. • Capabilities reference objects indirectly via their entries in the global object table. • Invalidate entry in global object table to revoke. CIT 380: Securing Computer Systems

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

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

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

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

24. How are ACL conflicts resolved? What happens when multiple ACL entries give different permissions to same subject? • First entry wins. • Last entry wins. • Deny wins over allow. CIT 380: Securing Computer Systems

25. What are the default permissions? • Interaction of ACLs with base permissions. • POSIX ACLs modify UNIX base 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

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

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

28. UNIX Access Control Model • UID • integer user ID • UID=0 is root • GID • integer group ID • Users can belong to multiple groups • Objects have both a user + group owner. • System compares object UID with EUID. • EUID identical except after su or SETUID. CIT 380: Securing Computer Systems

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

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

31. Special File Permissions Each object has set of special permission bits sticky • On a directory, means users can only delete files that they own setuid • Execute program with EUID = owner’s UID setgid • Execute program with EGID = owner’s GID • On directories, causes default group owner to be that of directory owner’s GID. CIT 380: Securing Computer Systems

32. Set specifiers u = user g = group o = other Permissions r = read w = write x = execute # remove other access chmod o-rwx *.c # add group r/w access chmod g+rw *.c # allow only you access chmod u=rwx * Changing Permissions: chmod CIT 380: Securing Computer Systems

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

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

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

36. setuid/setgid • Solution to UNIX ACLs inability to directly handle (user, program, file) triplets. • Process runs with EUID/EGID of file, not of user who spawned the process. • Follow principle of least privilege • create special user/groups for most purposes • Follow principle of separation of privilege • keep setuid functions/programs small • drop privileges when unnecessary CIT 380: Securing Computer Systems

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

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

39. Immutable Files Immutable Files on Linux • chattr +i • Cannot delete, rename, write to, link to • Applies to root too • Only root can remove immutable flag Immutable Files on FreeBSD • chflags +noschg • Cannot be removed by root in securelevel >0 CIT 380: Securing Computer Systems

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

41. Windows NT Access Control • Security IDs (SIDs) • users • groups • hosts • Token: user SID + group SIDs for a subject • ACLs on • files and directories • registry keys • many other objects: printers, IPC, etc. CIT 380: Securing Computer Systems

42. Standard NT Permissions • Read: read file or contents of a directory • Write: create or write files and directories • Read & Execute: read file and directory attributes, view directory contents, and read files within directory. • List Folder Contents: RX, but not inherited by files within a folder. • Modify: delete, write, read, and execute. • Full Control: all, including taking ownership and changing permissions CIT 380: Securing Computer Systems

43. Windows NT Conflict Resolution • If user not present in ACL and not a member of any group in ACL, access is denied. • If ACL explicitly denies user access, access is denied. • Otherwise, if user named in ACL, user has union of set of rights from each ACL entry in which user is named. CIT 380: Securing Computer Systems

44. Special NT Permissions • Traverse Folder/Execute File • List Folder/Read Data • Read Attributes • Read Extended Attributes • Create Files/Write Data • Create Folders/Append Data • Write Attributes • Write Extended Attributes • Delete Subfolders and Files • Delete • Read Permissions • Change Permissions • Take Ownership CIT 380: Securing Computer Systems

45. SQL Access Control • Subjects • Users. • Roles. create role faculty grant faculty to james • Objects • Databases, tables, table columns. • Rights • Select, insert, update, delete, references, grant. CIT 380: Securing Computer Systems

46. SQL Access Control • The grant command gives access to a user grant select on students to james or a role: grant select, insert, update on grades to faculty and includes power to grant options: grant insert on students to registrar with grant option • The revoke command removes access remove insert on grades from faculty CIT 380: Securing Computer Systems

47. 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. Availability • One process cannot deny access to CPU or other resources to kernel or other processes. CIT 380: Securing Computer Systems

48. 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. • 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

49. VM Address Translation CIT 380: Securing Computer Systems

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