CIS 5373 Systems Security

Transcription

1 CIS 5373 Systems Security Topic 3.2: OS Security Access Control Endadul Hoque

2 Slide Acknowledgment Contents are based on slides from Ninghui Li (Purdue), John Mitchell (Stanford), Bogdan Carbunar (FIU) 2

3 OS Security ACCESS CONTROL CONCEPTS 3

4 Access Control A reference monitor mediates all access to resources Principle: Complete mediation: control all accesses to resources Reference monitor User process access request? Resource policy 4

5 Access Matrix Model (Lampson 1971) Objects (and Subjects) F G S u b j e c t s U V r w own r r w own rights 5

6 Basic Abstractions Subjects Objects Rights The rights in a cell specify the access of the subject (row) to the object (column) 6

7 Objects An object is anything on which a subject can perform operations (mediated by rights) Usually objects are passive, for example: File Directory (or Folder) Memory segment But, subjects (i.e. processes) can also be objects, with operations performed on them kill, suspend, resume, send inter-process communication, etc. 7

8 Principals and Subjects A subject is a program (application) executing on behalf of some principal(s) A principal may at any time be idle, or have one or more subjects executing on its behalf What are subjects in UNIX? What are principals in UNIX? 8

9 Users and Principals USERS Real World User PRINCIPALS Unit of Access Control and Authorization the system authenticates the human user to a particular principal (in essence principal account) 9

10 Users and Principals There should be a one-to-many mapping from users to principals a user may have many principals, but each principal is associated with an unique user This ensures accountability of a user's actions Shared accounts (principals) are bad for accountability 10

11 Example Student Mail client TA PDF reader Webmaster User Principals Subjects 11

12 Principals and Subjects Usually (but not always) Each subject is associated with a unique principal All subjects of a principal have identical rights (equal to the rights of the invoking principal) This case can be modeled by a one-to-one mapping between subjects and principals For simplicity, we treat a principal and subject as identical concepts A user should always be viewed as multiple principals! 12

13 Access Matrix Model Objects (and Subjects) F G S u b j e c t s U V r w own r r w own rights 13

14 Access Matrix Implementation Access Matrix can be sparse Space inefficient Access Control Lists Capabilities 14

15 Access Control List ACL Maintained for each object (or subject) No entries when no permissions G: ACL U V V V r r w own Each column of the access matrix is stored with the object corresponding to that column 15

16 Capability Unforgeable token that gives possessor (user) certain rights Object to which access is permitted Right for the object F r How to make it unforgeable Capability giving the right to read object F 1. Only OS can access capability user gets a pointer 2. Encrypted capabilities access control mechanism has key 16

17 Capability List: C-List U F r F w F own F r Each row of the access matrix is stored with the subject corresponding to that row 17

18 ACLs vs Capabilities Access control list Associate list with each object Check user/group against list Relies on authentication: need to know user Capabilities Capability is unforgeable ticket Random bit sequence (or managed by OS) Can be passed from one process to another Reference monitor checks ticket Does not need to know identify of user/process 18

19 ACLs vs Capabilities ACL's provide for superior access review on a per-object basis Who has access to this object But hard to see to what a subject has access Capabilities provide for superior access review on a per-subject basis What capabilities does this subject have But hard to see who has access to an object 19

20 ACLs vs Capabilities Revocation: How to revoke access of a subject to an object ACL's provide for superior revocation facilities on a per-object basis Scan object s ACL Remove subject from list (if present) But hard to revoke all rights of a subject Capabilities provide for superior revocation facilities on a per-subject basis Hard to revoke all rights on an object (for all subjects) 20

21 ACLs vs Capabilities In real world, the per-object basis usually wins Most OSs protect files by means of ACL's Operations centered on objects Unix: use an abbreviated form of ACL's with just three entries owner group other 21

22 Roles (aka Groups) Role = set of users Administrator, PowerUser, User, Guest Assign permissions to roles; each user gets roles Role hierarchy Partial order of roles Each role gets permissions of roles below List only new permissions given to each role Administrator PowerUser User Guest 22

23 Role-Based Access Control (RBAC) Individuals Roles Resources engineering Server 1 marketing Server 2 human res Server 3 Advantage: users change more frequently than roles 23

24 Access Control Summary Access control involves reference monitor Check permissions: user info, action yes/no Important: must be no way to bypass this check Access control matrix Two implementations: access control lists vs capabilities Advantages and disadvantages of each Role-based access control Use group as user info ; use group hierarchies 24

25 OS Security UNIX ACCESS CONTROL 25

26 Unix What access control concepts are used? Truncated access control list A form of role-based access control File 1 File 2 User 1 read write - User 2 write write - User read Role r Read write write File 1 File 2 Owner read write - Group write write - Other - - read 26

27 Unix access control Process has user id Inherit from creating process Process can change id Restricted set of options Special root id All access allowed File 1 File 2 Owner read write - Group write write - Other - - read File has access control list (ACL) Grants permission to users Three roles : owner, group, other

28 Unix file access control list Each file has owner and group Permissions set by owner Read, write, execute Owner, group, other Represented by vector of four octal values rwx rwx rwx ownr grp othr Only owner, root can change permissions This privilege cannot be delegated or shared Setid bits Discuss in a few slides

29 Example directory listing access owner group size modification name

30 Process effective user id (EUID) Each process has three Ids (+ more under Linux) Real user ID (RUID) same as the user ID of parent (unless changed) used to determine which user started the process Effective user ID (EUID) from set user ID bit on the file being executed, or sys call determines the permissions for process (file access and port binding) Saved user ID (SUID) So previous EUID can be restored Real group ID, effective group ID, used similarly

31 Process Operations and IDs Root ID=0 for superuser root; can access any file Fork and Exec Inherit three IDs, except exec of file with setuid bit Setuid system call seteuid(newid) can set EUID to Real ID or saved ID, regardless of current EUID Any ID, if EUID is root Details are actually more complicated Several different calls: setuid, seteuid, setreuid

32 Setid bits on executable Unix file Three setid bits Setuid set EUID of process to ID of file owner Setgid set EGID of process to GID of file Sticky Off: if user has write permission on directory, can rename or remove files, even if not owner On: only file owner, directory owner, and root can rename or remove file in the directory Used only for directories

33 Example RUID 25 ; ; exec( ); Owner 18 SetUID program Owner 18 -rw-r--r-- file Owner 25 -rw-r--r-- file read/write read/write ; ; i=getruid() setuid(i); ; ; RUID 25 EUID 18 RUID 25 EUID 25

34 The need for setid bits Some operations are not modeled as files and require user id = 0 halting the system bind/listen on privileged ports (TCP/UDP ports below 1024) non-root users need these privileges File level access control is not fine-grained enough System integrity requires more than controlling who can write, but also how it is written 34

35 Security issues with setid bits These programs are typically setuid root Violates the least privilege principle every program and every user should operate using the least privilege necessary to complete the job Why violating least privilege is bad? How would an attacker exploit this problem? How to solve this problem? 35

36 Drop privilege A process that executes a set-uid program can drop its privilege; it can drop privilege permanently removes the privileged user id from all three user IDs drop privilege temporarily removes the privileged user ID from its effective uid but stores it in its saved uid, later the process may restore privilege by restoring privileged user ID in its effective uid 36

37 Example: User login login pid 2235 euid 0 ruid 0 suid 0 setuid(500) After the login process verifies that the entered password is correct, it issues a setuid system call. login pid 2235 euid 500 ruid 500 suid 500 exec( bash ) The login process then loads the shell, giving the user a login shell. bash pid 2235 euid 500 ruid 500 suid 500 fork() The user types in the passwd command to change his password. 37

38 bash pid 2235 euid 500 ruid 500 suid 500 bash pid 2297 euid 500 ruid 500 suid 500 exec( passwd ) passwd pid 2297 euid 0 ruid 500 suid 0 The fork call creates a new process, which loads passwd, which is owned by root user, and has setuid bit set. Drop privilege permanently Drop privilege temporarily passwd pid 2297 euid 500 ruid 500 suid 500 passwd pid 2297 euid 500 ruid 500 suid 0 38

39 Other Objects in Unix Accesses other than read/write/execute Who can change the permission bits? The owner can Who can change the owner? Only the superuser Rights not related to a file Affecting another process Operations such as shutting down the system, mounting a new file system, listening on a low port traditionally reserved for the root user 39

40 Unix access control summary Good things Some protection from most users Flexible enough to make practical systems possible Main limitation Coarse-grained ACLs user, group, other Too tempting to use root privileges No way to assume some root privileges without all

41 Coming up Network security 41