Operating system security Tuomas Aura CSEC 3400 Information

Operating system security Tuomas Aura CSE-C 3400 Information security Aalto University, autumn 2014

Outline Access control models in operating systems: 1. Windows 2. Unix 3. Alternatives Acknowledgements: This lecture material is partly based on a joint course with Dieter Gollmann 2

WINDOWS ACCESS CONTROL 3

Windows Security Model § Principals = users, machines, groups, … § Objects = files, Registry keys, printers, … § Each object has a discretionary access control list (DACL) § The active subjects are processes or threads running as a principal (i. e. acting on its behalf) § Each process (or thread) has an access token § When is a process allowed to access an object? – Object DACL is compared with the process’s access token when creating a handle to the object 4

Security indentifier § Principal names: machineprincipal or domainprincipal – aaltoaura, pc 3Administrators, ploveraura – Each principal has a unique security identifier (SID) – Names may change; SID is permanent § User SIDs: – S-1 -5 -21 -961468069 -954667678 -1722769278 -1002 = Alice – S-1 -5 -21 -961468069 -954667678 -1722769278 -500 = Administrator – Typical way to create unique user SIDs: S-1 -5 + machine or domain id + relative id § There are some well-known SIDs: – S-1 -5 -18 = Local System, S-1 -1 -0 = Everyone, S-1 -5 -domain-513 = Domain Users, etc. 5

Windows domains § Windows machine has a Local Security Authority (LSA), which can create local users and local groups (=aliases) – Local principals are stored in Registry § A Windows server can become a Domain Controller (DC), and other machines can join its domain § Domain administrators manage the domain users and groups centrally at the DC – Domain principals are stored in Active Directory (AD) – Names: domainprincipal or principal@domain § DC provides authentication services to other machines – Domain user can log into any domain-joined machine – Kerberos protocol used for distributed authentication § In large organizations, DCs and domains can form a hierarchy 6

Access token § Each process has an access token (=security token) § Token contains – Login user account SID (the process “runs as” this user) – SIDs of all groups in which the user is a member (recursively) – All privileges assigned to these groups § Privileges are special local access rights: – Backup, audit security log, take ownership, trusted for delegation, debugging, performance profiling, shutdown. etc. § Groups may be built-in or defined by admins: – Users, Administrators, Remote Desktop Users – Sales, Security Lab, Researchers, Europe Employees § Token never changes after it has been created – Better reliability and efficiency, slower revocation § Child process gets a copy of the parent’s token; it may be restricted 7

Objects § Objects: files, folder, Registry and AD objects, printers, processes. . . – Objects can be containers for other objects container hierarchy § Each object has a security descriptor, which includes the discretionary access control list (DACL) § Object also has an owner (identified by SID), who has the implicit right to read and write the DACL – This is discretionary access control 10

Permissions § Permissions are actions that apply to each object class § Some generic permissions are defined for all objects: read, write, execute, all, delete, etc. § Specific permissions are defined for each object class: Append, Add. Sub. Dir, Create. Thread, etc. § Permissions are encoded as a 32 -bit mask for fast checking § Object DACL specifies which principals (SIDs) have which permissions 11

Access control list (DACL) ACE 1 ACE 2 ACE 4 + + + Tuomaura Diego Lecturers EVERYONE Write Full Control Read, Write Read § DACL is a list of access control entries (ACE) § Negative ACEs are placed before positive ones § The above DACL grants read access but no write access to the user Tuomaura 12

Viewing the DACL and ACEs § Right-click on a file; select Properties/ Security § Note: Windows DACLs only exist in NTFS, not in FAT or other file systems § Click on Advanced to see the entire security descriptor DACL (list of ACEs) Permissions in the selected ACE 14

Access check algorithm § Process specifies the desired access (requested permissions) when creating a handle to the object § Privileges or implicit owner permissions may alone be sufficient for the requested access § Otherwise, Windows checks the DACL as follows: – Look for ACEs that match both (1) any SID in the subject’s access token and (2) any desired access right – If any negative ACE matches, deny access – If positive ACEs are found for all requested permissions, grant access – If the end of DACL is reached, deny access 15

Performance and reliability § Group membership and privileges are determined at login time – User’s group SIDs are cached in the token of the login process, and sub-processes get a copy – Token will not change even if a group membership or privilege is revoked from the user § Desired access is compared against the token and DACL when creating a handle to the object – not at access time – Changing file DACL does not affect open file handles § Consequences: – Better performance because of fewer checks – Better reliability because a process knows in advance whether it has sufficient access rights for a task – No immediate revocation of access rights 16

ACE inheritance + Diego Read, Write Flags: OBJECT_INHERIT Folder File A + Diego Read, Write Flags: INHERITED_ACE File B - Diego Write + Diego Read, Write Flags: INHERITED_ACE § Container objects can have inheritable ACEs § Inherited ACEs are copied to the end of contained-object DACLs; ACEs on the contained object come first and thus can override the inherited ones § Inherited ACEs are updated if the original one changes 17

Blocking inheritance + Diego Read Flags: OBJECT_INHERIT Folder X Folder Y Folder Z + Diego Read Flag: INHERITED_ ACE, INHERIT_ONLY File A File B + Diego Read, Write Flag: INHERITED_ACE 21 Flag: DACL_ PROTECTED

How to see them § Local users and aliases: > net user > net localgroup – Run compmgmt. msc, see System Tools / Local user and Groups § Domain users, groups and aliases: > net user /domain > net group /domain > net localgroup /domain (slow if it is a large domain!) (groups) (domain local groups*) § Members of a group, e. g. : > net group “Researchers“ /domain § Domain user information: > net user alice /domain § Privileges: – Run secpol. msc, see Local Policies / User Rights Assignment § Permissions: > icacls file. txt > icacls mydir /T /C *Not explained in this lecture (recursive) 23

UNIX ACCESS CONTROL 25

Principals § § The principals are users and groups Users have username and user identifier (UID) Groups have group name, group identifier (GID) UID and GID are usually 16 -bit numbers 0 = root 19057 = aura 100 = users § Both names and identifiers are permanent; difficult to change once selected – UID values often differ from system to system 26

User accounts § User accounts are stored in /etc/passwd § User account format: username: password: UID: GID: name: homedir: shell § Example: root: 7 k. SSI 2 k. Df: 0: 0: root: /bin/bash mail: x: 8: 12: mail: /var/spool/mail: news: x: 9: 13: news: /var/spool/news: ace: 69 ge. Dfelkw: 500: 103: Alice: /home/ace: /bin/bash carol: 7 fk. Kdefh 3 d: 501: 102: Carol: /home/carol: /bin/nologin tuomas: *: 502: 102: Tuomas Aura: /home/tuomas: /bin/tcsh al: : 503: 102: : /home/al: /bin/bash diego: RT. Qs. ZEEsx. T 92: 10026: 53: Dieter Gollmann: /home/staff/dieter: /bin/bash 27

Superuser § The superuser is a special privileged principal with UID zero and usually the user name root § There are few restrictions on the superuser – All security checks are turned off for the superuser – The superuser can become any other user § Examples: – The superuser cannot write to a read-only file system but can remount it as writeable – The superuser cannot decrypt passwords (because they are hash values) but can reset them 29

Groups § Users belong to one or more groups § The file /etc/group contains a list of all groups; entry format: groupname: password: GID: list of users § Example: § § infosecwww: *: 209: carol, al Every user belongs to a primary group; the group ID (GID) of the primary group is stored in /etc/passwd Depending on the Unix OS, user can belong to only one or many groups at the same time Usually only superuser can add groups and members Use the groups command to see your groups 30

Subjects § The subjects in Unix are processes; a process has a process ID (PID) § Processes can create new processes § Processes have a real UID and an effective UID (similarly for GID) § Real UID/GID: inherited from the parent; typically UID/GID of the user logged in § Effective UID/GID: inherited from the parent process or from the file being executed 31

Example Process /bin/login real UID effective real root GID effective system User diego logs on; the login process verifies the password and (with its superuser rights) changes its UID and GID (setuid(2), setguid(2)): /bin/login diego staff The login process executes the user’s login shell: /bin/bash diego staff From the shell, the user executes a command, e. g. ls /bin/ls diego staff The user executes command passwd to change his password: /bin/passwd diego root staff system 32

Objects § The objects of access control are files, directories and devices – Organized in a tree-structured file system § Directory is a file containing file names and pointers to inode data structures § Inode stores information about the object owner user and group, and permissions 33

Information about objects § Example: directory listing with ls -l -rw-r--r-- 1 diego staff 1617 Oct 28 11: 01 my. tex drwx------ 2 diego staff 512 Oct 25 17: 44 ads/ § File type: first character ‘-’ file ‘d’ directory ‘b’ block device file ‘c’ character device file ‘s’ socket ‘l’ symbolic link ‘p’ FIFO pipe § File permissions: nine characters § Link counter: the number of links (i. e. directory entries pointing) to the inode 34

Information about objects -rw-r--r-- 1 diego staff 1617 Oct 28 11: 01 my. tex drwx------ 2 diego staff 512 Oct 25 17: 44 ads/ § Username of the owner: usually the user that has created the file § Group: a newly created file usually belongs to its creator’s primary group § File size, modification time, filename § Owner and root can change permissions (chmod); root can change the file owner and group (chown) § User can change the file group to of its own groups § Filename is stored in the directory, not in inode, so that many names can be linked to the same inode 35

File permissions § Permission bits are grouped in three triples that define read, write, and execute access for owner, group, and other § rw-r--r-- read and write access for the owner, read access for group and other § rwx------ read, write, and execute access for the owner, no rights to group and other 36

Octal representation § File permissions can also be specified as octal numbers § Examples: rw-r--r-- is equivalent to 644; rwxrwxrwx is equivalent to 777 § Conversion table: 0040 read by group 0020 write by group 0010 execute by group 0004 read by other 0002 write by other 0001 execute by other 4000 set UID on execution 2000 set GID on execution 1000 set sticky bit 0400 read by owner 0200 write by owner 0100 execute by owner 37

SUID and SGID programs § SUID programs run with the effective UID of the owner of the executable file § For a SUID program, the execute permission of the owner is given as s instead of x: -rws--x—x 3 root bin 16384 Nov 16 1996 passwd* § SGID programs run with the effective GID of the owner of the executable file § For a SGID program, the execute permission of the group is given as s instead of x 38

Special modes for a directory § Sticky bit on an executable file historically indicated that the process should not be swapped to disk § Sticky bit on a directory restricts the deletion of files in that directory only to the file owners (and root) – Job queues for printing etc. , are often implemented as a worldwritable directories; anyone can add a file but not delete the files of others – /tmp § SGID bit on a directory means that new files inherit their group from the directory, not from the user who creates the file – Avoid running the print daemon as root: create a special group for the print daemon process and the print queue directory – Implement project directory where members can share files 42

Unix access control — dicsussion § Unix permissions have been standardized by IEEE as part of the POSIX standards (DOI 10. 1109/IEEESTD. 1992. 106983) – Fairly universal across Unix systems § Limitations and advantages? – Files have only one owner and group – Complex policies, e. g. access to several groups, are impractical to implement – Superuser needed for maintaining groups – All access rights (e. g. shutdown, create user) must be mapped to file access and to read, write and execute permissions – Relatively simple and widely understood – Relatively easy to check the protection state § Unix versions have subtle differences and may implement additional access control features 44

ALTERNATIVES 45

Access control lists in Unix Q: Are Unix file permissions a kind of ACL? Most Unix systems support additionally one of: § Posix ACL (standardization abandoned but widely implemented, see POSIX 1003. 1 e Draft 17) § Network File System NFSv 4 ACL (RFC 3550, section 5. 11) – Similar to Windows ACL with minor differences § Linux: – Many file systems (e. g. EXT 3, EXT 4, XFS) can be compiled with POSIX ACL support – NFS client and server map between POSIX and NFSv 4 ACLs 46

ACLs in Mac OS X § Mac OS X implement both POSIX permissions and NFSv 4 ACLs – Similar to Windows ACLs, but little used in OS X § Most files and folders do not have an ACL § When you set permissions in the graphical user interface and there are entries for more than one user or group, an ACL is created § ACLs are mostly used mainly to prevent accidental deletion of important folders: $ ls -led Movies drwx------+ 2 aura staff 68 14 Syy 20: 45 Movies 0: group: everyone deny delete $ rm -r Movies rm: Movies: Permission denied $ chmod +a# 0 "aura allow delete" Movies $ rm -r Movies 47

Security-Enhanced Linux (SELinux) § Mandatory access control for Linux servers – Originally developed by NSA, goal is security certification § Policy that cannot be changed by users – Modular policy language, complex policy definitions – Policy is compiled and installed by admin, not changed often § Hybrid access-control model: 1. Type enforcement – Subjects and objects have a type, rules based on the type 2. Multi-level security (e. g. Bell-La. Padula) – Level = sensitivity + category 3. Role-based access control (RBAC) § Each subject and object is labelled with security context user: role: type: level 48

SELinux discussion § SELinux is mainly used to lock down a server in case it has software vulnerabilities or Trojans – Types or categories are used for sandboxing processes § Developing and maintaining a new SELinux policy is a lot of work! – Original NSA reference policy is not usable – Tresys reference policy has commercial support – Red Hat Enterprise Linux tries to provide policies for common services – There are tools for policy validation and for learning policies by observing the system in operation 49

Mobile Operating Systems § Android, i. OS, Windows Phone § Subjects are apps, objects are phone features and services § Apps are given permissions – E. g. read contacts, send SMS, read camera roll, read GPS – User gives permissions at install time or when the permission is first needed – By default, apps can typically only access Internet and their own data § Apps are isolated from each other – Data can be shared only through special services that require permissions, e. g. photo library § No data sharing between apps through file system – Often , cloud file systems like Dropbox are used instead (Is that good? ) § Permissions are actually capabilities § Systems differ in the granularity of permissions and in user interaction § Learn much more in the course CSE-E 5480 Mobile Systems Security 50

Reading material § Dieter Gollmann: Computer Security, 2 nd ed. , chapter 6– 7; 3 rd ed. chapters 7– 8 § Matt Bishop: Introduction to computer security, chapter 25 § Ross Anderson: Security Engineering, 2 nd ed. , chapter 4 § Online: – John R. Michener, Understanding Windows File And Registry Permissions, MSDN Magazine, Nov 2008 http: //msdn. microsoft. com/en-us/magazine/cc 982153. aspx – Windows Development Reference, MSDN: http: //msdn. microsoft. com/enus/library/windows/desktop/aa 374876(v=vs. 85). aspx – Wayne Pollock, Unix File and Directory Permissions and Modes http: //content. hccfl. edu/pollock/AUnix 1/File. Permissions. htm 51

Exercises: Windows § How can Unix file permissions be expressed with Windows ACLs? § Assume Fred is member of group Lecturers. Who gets access to an object with the DACLs: 1. [-, Fred, READ], [+, Lecturers, READ] ? 2. [-, Lecturers, READ], [+, Fred, READ] ? 3. [+, Fred, READ], [-, Lecturers, READ] ? § When a new object is created, what goes to its security descriptor? § Access tokens are objects themselves. How does access control for the tokens work? § What is the time-of-check-to-time-of-use (TOCTTOU) issue? Where does this create potential problems in the Windows file system? § There is no Windows API for giving file ownership to others. Administrators have backup and restore privileges. What trick can they use to change file owner? § Changing permissions on a top-level folder in the NTFS file system is a very slow operation. You can try by creating new user and giving it read access to C: . This is actually a performance optimization. Explain why. 52

Exercises: Unix § Create a subdirectory in your home directory and put a file abc. txt in this subdirectory. Set permission bits on the subdirectory so that the owner has only execute access. Try to – – list the subdirectory display the contents of abc. txt create a copy of abc. txt in the subdirectory make the subdirectory the current directory with cd § Repeat the same experiment first with read permission and then with write permission on the subdirectory. Try to understand what you observe. § Find out how permissions are used to protect a files on a web server, a shared temp directory, print queue directory, or shared directory for a project group. § Write and configure a SUID program in C that allows other users to write log messages to a file which they otherwise cannot access. What if there is a buffer overflow vulnerability or other bugs in your code? § Devices in Unix are mapped to special files under /dev. How would you protect a terminal (tty) device from other users? 53