operating system security n.
Skip this Video
Loading SlideShow in 5 Seconds..
Operating system security PowerPoint Presentation
Download Presentation
Operating system security

Loading in 2 Seconds...

play fullscreen
1 / 40

Operating system security - PowerPoint PPT Presentation

  • Uploaded on

Operating system security. Aalto University , autumn 2013. Outline. Access control models in operating systems: Windows Unix. Acknowledgements: This lecture material is partly based on a joint course with Dieter Gollmann. Windows access control. Windows Security Model.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Operating system security' - tiara

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
operating system security

Operating system security

Aalto University, autumn 2013


Access control models in operating systems:

  • Windows
  • Unix

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

windows security model
Windows Security Model
  • Principals = users, machines, groups,…
  • Objects = files, Registry keys, printers, …
  • Each object has an discretionary access control list (DACL)
  • The active subjectsare processes and threads
  • 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
security indentifier
Security indentifier
  • Principal names: machine\principal or domain\principal
    • Aalto\aura, pc3\Administrators, plover\aura = Tuomas 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 use SIDs:S-1-5 + machine or domain id + relative id
  • Well-known SIDs:
    • S-1-5-18 = Local System, S-1-1-0 = Everyone, S-1-5-domain-513 = Domain Users, etc.
windows domains
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
    • 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
access token
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
    • etc.
  • 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
  • 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 contains 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
  • 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
  • Object DACL specifies which principals (SIDs) have which permissions
access control list dacl
Access control list (DACL)
  • DACL is a list of access control entries (ACE)
  • Negative ACEsareplacedbeforepositiveones
  • The above ACL grants read access but no write access to the user Tuomaura
viewing the dacl and aces
Viewing the DACL and ACEs
  • Right-click on a file; select Properties/Security
  • Note: DACLs only exist in NTFS, not in FAT or other file systems
  • Click on Advanced to see the entire security descriptor


Permissions for the selected ACE

access check algorithm
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, check DACL as follows:
    • Look for ACEs that match both (1) any SID in the subjects 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
performance and reliability
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 membership or privilege is revoked from a SID
  • 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
ace inheritance
ACE inheritance
  • Container objects can have inheritable ACEs
  • Inherited ACEs are copied to the end of contained-object DACLs; aces on the contained object can override them
  • Inherited ACEs are updated if the original one changes


File A

File B

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


File A

File B

blocking inheritance
Blocking inheritance

Folder X

Folder Y

Folder Z



File A

File B

how to see them
How to see them
  • Local users and aliases: > net user > net localgroup
    • Runcompmgmt.msc, see System Tools / Localuser 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:
    • Runsecpol.msc, seeLocalPolicies / User Rights Assignment
  • Permissions:

> icacls file.txt

> icaclsmydir /T /C (recursive)

*Notexplained in thislecture

restricted tokens
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 groups, which 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
  • 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
user accounts
User accounts
  • User accounts are stored in /etc/passwd
  • User account format:


  • Example:






tuomas:*:502:102:Tuomas Aura:/home/tuomas:/bin/tcsh


dieter:RT.QsZEEsxT92:10026:53:Dieter Gollmann:/home/staff/dieter:/bin/bash

  • The superuseris 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
  • Users belong to one or more groups
  • The file /etc/group contains a list of all groups; file entry format:

groupname:password:GID:list of users

  • Example:


  • 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 groupscommand to see your groups
  • The subjectsin 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


Process real effective real effective

/bin/login root root system system

User dieter logs on; the login process verifies the password and (with its superuser rights) changes its UID and GID (setuid(2), setguid(2)):

/bin/login dieter dieter staff staff

The login process executes the user’s login shell:

/bin/bash dieter dieter staff staff

From the shell, the user executes a command, e.g. ls

/bin/ls dieter dieter staff staff

The user executes command passwd to change his password:

/bin/passwd dieter root staff system

  • The objectsof access control are files, directories and devices
    • Organized in a tree-structured file system
  • Directory is a filecontainingfilenames and pointers to inode data structures
  • Inodestores information about the object owner user and group, and permissions
information about objects
Information about objects
  • Example: directory listing with ls -l

-rw-r--r-- 1 dieter staff 1617 Oct 28 11:01 my.tex

drwx------ 2 dieter 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
information about objects1
Information about objects

-rw-r--r-- 1 dieter staff 1617 Oct 28 11:01 my.tex

drwx------ 2 dieter 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
file permissions
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
file permissions1
File permissions
  • SUID programs run with the effective UID of the owner of the executable file
  • When ls –l displays a SUID program, the execute permission of the owner is given ass 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
  • When ls –l displays a SGID program, the execute permission of the group is given ass instead of x
octal representation
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 execution

0020 write by group 2000 set GID on execution

0010 execute by group 1000 set sticky bit

0004 read by other 0400 read by owner

0002 write by other 0200 write by owner

0001 execute by other 0100 execute by owner

permissions for directories
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?
special modes for a directory
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 the superuser)
    • 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 print queue directory
    • Implement project directory where members can share files
default permissions
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 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
unix access control dicsussion
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 maintaininggroups
    • All access rights (e.g. shutdown, create user) must be mapped to file access and to read, write and executepermissions
    • Relatively simple and widely understood
    • Relatively easy to check the protection state
  • Unix versions have subtle differences and may implement additional access control features
access control lists in unix
Access controllists in Unix
  • Are Unix file permissions an ACL?

Most Unix systemssupportadditionallyone of:

  • Posix ACL(standardizationabandonedbutwidelyimplemented, seePOSIX 1003.1e Draft 17)
  • NetworkFile System NFSv4 ACL(RFC 3550, section 5.11)
    • Similar to Windows ACL with minordifferences
  • Linux:
    • Manyfilesystems (e.g. EXT3, EXT4, XFS) canbecompiled with POSIX ACL support
    • NFS client and servermapbetween POSIX and NFSv4 ACLs
acls in mac os x
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
  • 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

reading material
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
exercises unix
Exercises: Unix
  • Create a subdirectory in your home directory and put a file abc.txtin 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.txtin the subdirectory
    • make the subdirectory the current directory with cd
  • Repeat the same experiment first with readpermission 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 ad configure a SUID program in C that allows other users to write log messages to a 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?
exercises windows
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:
    • [-,Fred,READ], [+, Lecturers,READ] ?
    • [-, Lecturers,READ], [+,Fred,READ] ?
    • [+,Fred,READ], [-, Lecturers,READ] ?
  • When a new object is created, how is its security descriptor ‘populated’?
  • 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 (such as C:\ or C:\Program Files) is very slow operation. This is actually a performance optimization. Explain why.