Operating system security

Tuomas AuraCSE-C3400 Information security

Aalto University, autumn 2014

Outline

Access control models in operating systems:

1. Windows

2. Unix

3. Alternatives

2

Acknowledgements: This lecture material is partly based on a joint course with Dieter Gollmann

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: machine\principal or domain\principal

– aalto\aura, pc3\Administrators, plover\aura – 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: domain\principal 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

Creating subjects

The machine is always running a logon process (winlogon.exe) as the principal SYSTEM

When a user logs on to a machine, – the logon process asks for user credentials (e.g.

password) and presents them to the LSA

– the LSA (lsass.exe) verifies the credentials

– the logon process starts a shell (explorer.exe) running as the user (=principal) and in a new logon session

Shell spawns processes to the same logon session

Logging off destroys the logon session and all processes in it– Note: Windows has no equivalent of disown/nohup. To leave a program running in the background, create a service.

8

Background info

Creating more subjects

A process can spawn a new local process (subject) by calling e.g. CreateProcess– Each process has its own access token

– New process gets a copy of its parent’s token

– Threads can be given their own tokens, so that they become independent subjects

User’s network credentials (e.g. password or Kerberos ticket) are cached in the logon session Process can create network logon sessions for the local login user user at other machines

9

Background info

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, AddSubDir, CreateThread, 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)

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

ACE1 - Tuomaura Write

ACE2 + Diego Full Control

ACE2 + Lecturers Read, Write

ACE4 + EVERYONE Read

Access control entry (ACE)

ACE format:

13

Type: positive or negative (grant or deny)

Permissions: actions to grant to deny

Principal (SID): who the ACE applies to

Flags

Object Type

Inherited Object Type

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

14

Permissions in

the selected ACE

DACL

(list of ACEs)

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

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 changes17

Folder

File A File B

+ Diego Read, Write Flags: OBJECT_INHERIT

- Diego Write

+ Diego Read, Write

Flags: INHERITED_ACE

+ Diego Read, Write

Flags: INHERITED_ACE

Container hierarchy

18

Folder X

Folder Y Folder Z

+ Diego Read, Write Flags: OBJECT_INHERIT, INHERIT ONLY

- Diego Write

Flags: OBJECT_INHERIT

+ Diego Read, Write

Flags: INHERITED_ACE

INHERIT_ONLY,

OBJECT_INHERIT

+ Diego Read, Write

Flags: INHERITED_ ACE,

INHERIT ONLY, OBJECT_INHERIT

File A File B - Diego Write

Flags: INHERITED_ACE

+ Diego Read, Write

Flags: INHERITED_ACE

+ Diego Read, Write

Flags: INHERITED_ACE

ACE inheritance

Inheriting negative ACEs

It is possible to override inherited negative ACEs because inherited ACES are placed at the end of the list

19

Folder

File A File B

- Tuomaura Read Flags: OBJECT_INHERIT

+ Tuomaura Read

- Tuomaura Read

Flags: INHERITED_ACE

- Tuomaura Read

Flags: INHERITED_ACE

Inheritance flags Flags on ACEs:

20

OBJECT_INHERIT_ACE ACE applies to leaf objects

CONTAINER_INHERIT_ACE ACE applies to container objects

NO_PROPAGATE_INHERIT_ACE Applies to immediate children only

INHERIT_ONLY_ACE Does not apply to the container itself

INHERITED_ACE The ACE has been inherited

SE_DACL_PROTECTED This object does not inherit from

containers above itself

(Inheritable ACEs can apply to leaf objects, to containers, or to both)

Flags on DACLs:

21

Flag: DACL_PROTECTED

Blocking inheritance

Folder X

Folder Y Folder Z

+ Diego Read Flags: OBJECT_INHERIT

File A File B

+ Diego Read, Write

Flag: INHERITED_ACE

+ Diego Read

Flag: INHERITED_ ACE,

INHERIT_ONLY

Advanced inheritance Inheritance simplifies system administration but very few

users and developers understand or use it Object hierarchies with inheritance:

NTFS, Registry, Active Directory Inheritable ACEs can apply only to leaf objects or only to

containers (as seen earlier) Inheritable ACEs can apply to all objects or only to a specific

object type Special CREATOR_OWNER SID in an ACE indicates that the

ACE matches to the owner of the object Performance trade-off:

– Inherited ACEs are cached in sub-object DACLs to make access control decisions faster

– Changes in permissions at the root of a file system are copied down the hierarchy, which is slow. However, such changes are rarely made by applications but sometimes by system admins

22

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 (slow if it is a large domain!)> net group /domain (groups)> net localgroup /domain (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 (recursive)

23*Not explained in this lecture

Restricted tokens

Access token inherited by a process may give it too many access rights

Process may create a restricted token– remove privileges

– disable groups: change SIDs to “deny-only” mode; they are not deleted but marked as USE_FOR_DENY_ONLY

– add restricted SIDs: a second list of SIDs that is also compared against DACLs

Process can assign restricted tokens to its child processes or threads

Typically used in services, rarely in desktop apps

24

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:7kSSI2k.Df:0:0:root:/root:/bin/bash

mail:x:8:12:mail:/var/spool/mail:

news:x:9:13:news:/var/spool/news:

ace:69geDfelkw:500:103:Alice:/home/ace:/bin/bash

carol:7fkKdefh3d: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.QsZEEsxT92:10026:53:Dieter Gollmann:/home/staff/dieter:/bin/bash

27

User account details

User name: up to eight characters long

Password: stored “encrypted” (really a hash)

User ID: user identifier for access control

group ID: user’s primary group

ID string: user's full name

Home directory

Login shell: the program started after successful log in

28

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

32

UID GIDProcess real effective real effective/bin/login root root system 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 diego staff staff

The login process executes the user’s login shell:/bin/bash diego diego staff staff

From the shell, the user executes a command, e.g. ls/bin/ls diego diego staff staff

The user executes command passwd to change his password:/bin/passwd diego root staff system

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

34

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 ‘s’ socket

‘b’ block device file ‘l’ symbolic link

‘c’ character device file ‘p’ FIFO pipe

File permissions: nine characters

Link counter: the number of links (i.e. directory entries pointing) to the inode

35

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

36

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

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 4000 set UID on execution0020 write by group 2000 set GID on execution0010 execute by group 1000 set sticky bit0004 read by other 0400 read by owner0002 write by other 0200 write by owner0001 execute by other 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

SUID to root When root owns an executable file and the SUID bit is set, the

process will get superuser status during execution Important SUID programs:

/bin/passwd change password /bin/login login program /bin/at batch job submission /bin/su change UID program

Only processes running as root can listen at the privileged TCP or UDP ports 0–1023

SUID programs need to be written very carefully so that their privileges cannot be misused and they only do what is intended

Principle of least privilege:– Often better to define a new user and group for specific purpose, e.g.

print daemon or database admin, than to suid to root– Process can use functions seteuid(2) and setegid(2) to

toggle between privileged and non-privileged identifiers

39

Access control decisions Access control uses the effective UID/GID:

– If the subject’s UID owns the file, the permission bits for owner decide whether access is granted

– If the subject’s UID does not own the file but its GID does, the permission bits for group decide whether access is granted

– If the subject’s UID and GID do not own the file, the permission bits for other (also called world) decide whether access is granted

Note that although the permission bits may give the owner less access than to others, the owner can always change the permissions (discretionary access control)

40

Permissions for directories

Read permission: to find which files are in the directory, e.g. for executing ls

Write permission: to add files and delete files

Execute permission: to make the directory the current directory (cd) and for opening files inside the directory

E.g. every user has a home directory; what are the correct permissions for the home directory?

41

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

writable 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

Default permissions Unix utilities typically use default permissions 666 for a new

data file and 777 for a new executable file Permissions can be restricted with umask: a three-digit

octal number specifying the rights that should be withheld File permissions = default permissions AND (NOT umask)

Sensible umask values:– 022: all permissions for the owner, read and execute permission

for group and other– 037: all permissions for the owner, read permission for group,

no permissions for other– 077: all permissions for the owner, no permissions for group and

other

Example: default permissions 666, umask 077 permissions for new file 0600

43

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 UnixQ: 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.1e Draft 17)

Network File System NFSv4 ACL(RFC 3550, section 5.11)– Similar to Windows ACL with minor differences

Linux:– Many file systems (e.g. EXT3, EXT4, XFS) can be compiled

with POSIX ACL support– NFS client and server map between POSIX and NFSv4 ACLs

46

ACLs in Mac OS X Mac OS X implement both POSIX permissions and NFSv4 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-LaPadula)– Level = sensitivity + category

3. Role-based access control (RBAC) Each subject and object is labelled with security contextuser: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, iOS, 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-E5480 Mobile Systems Security50

Reading material Dieter Gollmann: Computer Security, 2nd ed.,

chapter 6–7; 3rd ed. chapters 7–8 Matt Bishop: Introduction to computer security,

chapter 25 Ross Anderson: Security Engineering, 2nd ed.,

chapter 4 Online:

– John R. Michener, Understanding Windows File And Registry Permissions, MSDN Magazine, Nov 2008http://msdn.microsoft.com/en-us/magazine/cc982153.aspx

– Windows Development Reference, MSDN: http://msdn.microsoft.com/en-us/library/windows/desktop/aa374876(v=vs.85).aspx

– Wayne Pollock, Unix File and Directory Permissions and Modes http://content.hccfl.edu/pollock/AUnix1/FilePermissions.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