Lecture 18 Overview

Protected Objects CPU Memory I/O devices (disks, printers, keyboards,...)‏ Programs Data Networks CS 450/650 Lecture 18: Protection in Operating System

Separation Physical separation Temporal separation Logical separation Use different physical resources for different users Temporal separation Execute users' programs at different times Logical separation Gives the impression that no other users exist Cryptographic separation Encrypt data and make it unintelligible to outsiders CS 450/650 Lecture 18: Protection in Operating System

Sharing Sometimes, users want to share resources Library routines (e.g., libc)‏ Files or database records OS should allow flexible sharing, not “all or nothing” Which files or records? Which part of a file/record? Which other users? Can other users share objects further? What uses are permitted? Read but not write, view but not print (Feasibility?)‏ Aggregate information only For how long? CS 450/650 Lecture 18: Protection in Operating System

Protection Techniques Fence register Exception if memory access below address in fence register Protects operating system from user programs Single user only CS 450/650 Lecture 18: Protection in Operating System

Protection Techniques Base/bounds register pair Exception if memory access below/above address in base/bounds register Different values for each user program Maintained by operating system during context switch Limited flexibility CS 450/650 Lecture 18: Protection in Operating System

Protection Techniques Tagged architecture Each memory word has one or more extra bits that identify access rights to word Very flexible Large overhead Difficult to port OS from/to other hardware architectures CS 450/650 Lecture 18: Protection in Operating System

Segmentation use different segments for code, data, stack or maybe even more fine-grained Virtual addresses consist of two parts: <segment name, offset within segment> OS keeps mapping from segment name to its base physical address in Segment Table Each segment has its own memory protection attributes CS 450/650 Lecture 18: Protection in Operating System

Logical and Physical Representation of Segments CS 450/650 Lecture 18: Protection in Operating System

Translation of Segment Address Segment Table also contains memory protection attributes CS 450/650 Lecture 18: Protection in Operating System

Review of Segmentation Advantages: Each address reference is checked for protection by hardware Many different classes of data items can be assigned different levels of protection Users can share access to a segment with potentially different access rights Users cannot access an unpermitted segment CS 450/650 Lecture 18: Protection in Operating System

Review of Segmentation Disadvantages: External fragmentation Dynamic length of segments requires costly out-of-bounds check for generated physical addresses Segment names are difficult to implement efficiently CS 450/650 Lecture 18: Protection in Operating System

Paging Program is divided into equal-sized chunks pages Physical memory is divided into equal-sized chunks frames Virtual addresses consist of two parts: <page #, offset within page> # bits for offset = log2(page size), no out-of-bounds possible for offset CS 450/650 Lecture 18: Protection in Operating System

Page Address Translation CS 450/650 Lecture 18: Protection in Operating System

Review of Paging Advantages: Disadvantages: Each address reference is checked for protection by hardware Users can share access to a page, with potentially different access rights Users cannot access an unpermitted page Disadvantages: Internal fragmentation Assigning different levels of protection to different classes of data items not feasible CS 450/650 Lecture 18: Protection in Operating System

Paged Segmentation CS 450/650 Lecture 18: Protection in Operating System

x86 Architecture x86 architecture provides both segmentation and paging Memory protection bits indicate no access, read/write access or read-only access Recent x86 processors also include NX (No eXecute) bit, forbidding execution of instructions stored in page Helps against some buffer overflows CS 450/650 Lecture 18: Protection in Operating System

Lecture 19 Protection in Operating System (cont) CS 450/650 Fundamentals of Integrated Computer Security Slides are modified from Ian Goldberg and Hesham El-Rewini

Access Control Every object to be protected is within one or more protection domains O2 Domain 1 O1 Domain 2 Domain 3 O2 O4 O1 O3 CS 450/650 Lecture 19: Access Control

Access Rights Domain 1 Domain 3 Domain 2 <O2, {execute}> <O1, {read,write}> Domain 1 Domain 3 Domain 2 <O1, {execute}> <O3, {read}> <O2, {write}> <O4, {print}> CS 450/650 Lecture 19: Access Control

Access Control In general, access control has three goals: Check every access: Else OS might fail to notice that access has been revoked Enforce least privilege: Grant program access only to smallest number of objects required to perform a task Access to additional objects might be harmless under normal circumstances, but disastrous in special cases Verify acceptable use: Limit types of activity that can be performed on an object e.g., for integrity reasons CS 450/650 Lecture 19: Access Control

Directory CS 450/650 Lecture 19: Access Control

Directory Issues List becomes too large if many shared objects are accessible to all users Deletion must be reflected in all directories Revocation of access Must search all users to see access Large systems can easily have 5,000 to 10,000 active accounts Pseudonyms Multiple permissions CS 450/650 Lecture 19: Access Control

Access Control Lists (ACLs)‏ Each object has a list of subjects and access rights CS 450/650 Lecture 19: Access Control

Access Control Lists Which of the following can we do quickly for ACLs? Determine set of allowed users per object Determine set of objects that a user can access Revoke a user’s access right to an object or all objects CS 450/650 Lecture 19: Access Control

Access Control Lists ACLs are implemented in NTFS file system, user entry can denote entire user group e.g., “Students” Classic UNIX file system has simple ACLs Each file lists its owner, a group and a third entry representing all other users For each class, there is a separate set of rights Groups are system-wide defined in /etc/group use chmod/chown/chgrp for setting access rights to your files CS 450/650 Lecture 19: Access Control

Access Control Matrix Set of protected objects: O Set of subjects: S e.g., files or database records Set of subjects: S e.g., humans, processes acting on behalf of humans or group of humans/processes Set of rights: R e.g., {read, write, execute, own} Access control matrix consists of entries a[s,o] where s  S, o  O and a[s,o]  R CS 450/650 Lecture 19: Access Control

Example Access Control Matrix rx Carol orx r Bob o orw Alice File 3 File 2 File 1 CS 450/650 Lecture 19: Access Control

Implementing Access Control Matrix Access control matrix is hardly ever implemented as a matrix Matrix would likely be sparse Instead, ordered triples (Alice, File1, {o,r,w}) (Alice, File2, {r,x}) (Alice, File3, {o}) (Bob, File1, {r}) (Bob, File2, {o,r,x}) (Carol, File2, {r,x}) CS 450/650 Lecture 19: Access Control

Capabilities A capability is an unforgeable token that gives its owner some access rights to an object e.g., Alice: {File 1:orw}, {File 2:rx}, {File 3:o} Unforgeability enforced by having OS store and maintain tokens by cryptographic mechanisms digital signatures, allows tokens to be handed out to processes/users OS will detect tampering when process/user tries to get access with modified token Owner of token might be allowed to transfer token to others CS 450/650 Lecture 19: Access Control

Capabilities transfer or propagate right Domain A subject having this right can pass copies of capabilities to other subjects Domain collection of objects to which the process has access CS 450/650 Lecture 19: Access Control

Combining ACLs and Capabilities In some scenarios, it makes sense to use both ACLs and capabilities e.g., for efficiency reasons In a UNIX file system, each file has an ACL, which is consulted when executing an open() call If approved, caller is given a capability listing type of access allowed in ACL (read or write)‏ Capability is stored in memory space of OS Upon read()/write() call, OS looks at capability to determine whether type of access is allowed CS 450/650 Lecture 19: Access Control

Kerberos requires two systems which are both part of the key distribution center (KDC) authentication server (AS) and ticket-granting server (TGS) A user presents an authenticating credential (such as a password) to the AS receives a ticket showing that the user has passed authentication single sign-on: user signs on once from that point on all the user's (allowable) actions are authorized without the user needing to sign on again CS 450/650 Lecture 19: Access Control

Procedure-Oriented Access Control A procedure controls access to objects the procedure forms a capsule around the object permitting only certain specified accesses can ensure that accesses to an object be made through a trusted interface implements the principle of information hiding carries a penalty of inefficiency CS 450/650 Lecture 19: Access Control

Role-based Access Control (RBAC)‏ In general, objects that a user can access often do not depend on the identity of the user, but on the user’s role within the organization e.g., salesperson can access customers’ credit card numbers, marketing person only customer names In RBAC, administrator assigns users to roles and grants access rights to roles When a user takes over new role, need to update only her role assignment not all her access rights CS 450/650 Lecture 19: Access Control

Role Based Access Control Role Hierarchies A user can be a member of many roles Each role can have many users as members A permission can be assigned to many roles Each role can have many permissions read, write, append, execute Usrer-Role Assignment Permission-Role Assignment USERS ROLES PERMISSIONS ... Sessions CS 450/650 Lecture 19: Access Control

Task Based Access Control Classical subject-object access control P S x O x A TBAC view of access control P S x O x A x U x AS TBAC extensions P – Permission S – Subject O – Object A – Actions U – Usage and Validity Counts AS – Authorization step No Roles Involved For each authorization step consumes permission, usage count is incremented Usage Count reaches its limit, the associated permission is deactivated Every authorization-step maintains its own protection state. The initial value of a protection state is the set of permissions that are turned on (active) as a result of the authorization-step becoming valid. However, the contents of this set will keep changing as an authorization-step is processed and the relevant permissions are consumed. With each permission we associate a certain usage count. When a usage count has reached its limit, the associated permission is deactivated and the corresponding action is no longer allowed. Conceptually, we can think of an active permission as a check-in of the permission to the protection-state and a deactivation of a permission as a check out from the protection state. This constant and automated check-in and checkout of permissions as authorizations are being processed is one of the central features that make TBAC an active model. Further, the protection states of individual authorization-steps are unique and disjoint. What this means is that every permission in a protection state is uniquely mapped to an authorization-step instance and to the task or sub-task instance that is invoking the authorization. This ability to associate contextual information with permissions is absent in typical subject-object style access control models. CS 450/650 Lecture 19: Access Control

Task Role Based Access Control Permissions are assigned to tasks rather than roles In Workflow Authorization Model, subjects gain access to the required objects only during the execution of the task User-Role Assignment Role-Task Assignment Task-Permission Assignment USERS ROLES TASKS PERMISSIONS CS 450/650 Lecture 19: Access Control

Access Control Policies Specification of how each user is authorized to use each resource In practice, no computer applies a single policy to manage all of its resources Scheduling algorithms for CPU  SJF, RR Storage  paging, segmentation CS 450/650 Lecture 19: Access Control

User Authentication CS 450/650 Lecture 19: Access Control

User Authentication Systems often have to identify and authenticate users OS when a user logs in Web server before handing out confidential info Identification and authentication is easy among people that know each other We identify our friends based on their face or voice More difficult for computers to authenticate people sitting in front of them Even more difficult for computers to authenticate people accessing them remotely CS 450/650 Lecture 19: User Authentication

Authentication Factors Something the user knows User name and password, PIN, secret question Something the user has ATM card, badge, cookie, physical key, uniform Something the user is Biometrics (fingerprint, voice pattern, face,…)‏ Have been used by humans forever, but only recently by computers Something about the user’s context Location, time CS 450/650 Lecture 19: User Authentication

Authentication Factors “Something you have” can become “something you know” If token can be easily duplicated, such as magnetic strip on ATM card That’s why ATM fraud is so wide spread Some banks distribute small devices displaying numbers that change over time Current number needs to be input for online banking However, knowing number does not imply physical possession of device CS 450/650 Lecture 19: User Authentication

Combination of Auth. Factors Different classes of authentication factors can be combined for more solid authentication Two- or multi-factor authentication Using multiple factors from the same class might not provide better authentication CS 450/650 Lecture 19: User Authentication

Passwords Probably oldest authentication mechanism User enters user ID and password Usability problems Entering passwords is inconvenient If password is disclosed to unauthorized individual, the individual can immediately access protected resource Unless we use multi-factor authentication If password is shared among many people, password updates become difficult CS 450/650 Lecture 19: User Authentication

Password Guessing Attacks Brute-force: Try all possible passwords using exhaustive search It’s possible to test 350K Microsoft Word passwords per second on a 3-GHz Pentium For passwords of length 8 consisting only of letters, there are about 2*1011 possibilities It takes only 166 hours to test all of them Expected wait till success is 83 hours Easy to buy more hardware if payoff is worth it CS 450/650 Lecture 19: User Authentication

Password Guessing Attacks Can make attack harder by including digits and special characters in password However, exhaustive search assumes that people choose passwords randomly, which is often not the case Attacker can do much better by exploiting this observation CS 450/650 Lecture 19: User Authentication

Password Guessing Attacks Password Recovery Toolkit (PRTK) assumes that a password consists of a root and a pre- or postfix appendage “password1”, “abc123”, “123abc” Root is taken from dictionaries names, English words,… Appendage is two-digit combination date, single symbol,… CS 450/650 Lecture 19: User Authentication

Password Guessing Attacks Attack requires that attacker has encrypted password file or encrypted document Offline attack Instead attacker might want to guess your banking password Online attack Online guessing attacks are detectable Bank shuts down online access to your bank account after n failed login attempts typically n ≤ 5 CS 450/650 Lecture 19: User Authentication

Choosing Good Passwords Use letters, numbers and special characters Choose long passwords At least eight characters Avoid guessable roots If supported, use pass phrase Mix upper and lower case introduce misspellings and special characters Avoid common phrases e.g., advertisement slogans CS 450/650 Lecture 19: User Authentication

Password Hygiene Writing down passwords is more secure than storing many passwords on a networked computer or re-using same password across multiple sites Unreasonable to expect users to remember long passwords, especially when changed often Requires physical security for password sheet, don’t use sticky notes CS 450/650 Lecture 19: User Authentication

Password Hygiene Change passwords regularly Especially if shorter than eight characters Should users be forced to change their password? Leads to password cycling and similar “myFavoritePwd” -> “dummy” -> “myFavoritePwd” goodPwd.”1” -> goodPwd.”2” -> goodPwd.”3” CS 450/650 Lecture 19: User Authentication

Password Hygiene Don’t reveal passwords to others In email or over phone If your bank really wants your password over the phone, switch banks Don’t enter password that gives access to sensitive information on a public computer Don’t do online banking on them CS 450/650 Lecture 19: User Authentication

Attacks on Password Files Systems need to store information about a password in order to validate given password Storing passwords in plaintext is dangerous, even when file is read protected from users Password file might end up on backup tapes Intruder into OS might get access to password file System administrator has access to file and might use passwords to impersonate users at other sites Many people re-use passwords across multiple sites

Defending against Attacks Store only a digital fingerprint of the password in the password file using cryptographic hash When logging in, system computes fingerprint of entered password and compares it with user’s stored fingerprint Still allows guessing attacks when password file leaks CS 450/650 Lecture 19: User Authentication

Defending against Attacks UNIX makes these attacks harder by storing user-specific salts in the password file Salt is derived from time of day and process ID of /bin/passwd Salt is included when computing password fingerprint Two users who happen to have the same password will have different fingerprints Makes guessing attacks harder, can’t just build a single table of fingerprints and passwords and use it for any password file CS 450/650 Lecture 19: User Authentication

Defending against Attacks Store an encrypted version of the password in the password file Need to keep encryption key away from attackers As opposed to fingerprints, this approach allows system to easily re-compute password if necessary e.g., have system email password to predefined email address when user forgets password Has become the norm for many websites

Interception Attacks Attacker intercepts password while it is being transmitted to website One-time passwords make intercepted password useless for later logins In a challenge-response protocol, the server sends a random challenge to the client Client uses challenge and password as an input to a function and computes a one-time password Client sends one-time password to server Server checks whether client’s response is valid Given intercepted challenge and response, attacker might be able to brute-force password CS 450/650 Lecture 19: User Authentication

Interception Attacks Proposed solutions are difficult to deploy Changes to HTTP protocol required i.e., every browser and many servers would have to be changed Challenge-response functions need to be irreversible, but also computable by humans for easy deployment which makes them rare CS 450/650 Lecture 19: User Authentication

Graphical Passwords Graphical passwords are an alternative to text- based passwords Multiple techniques, e.g., User chooses a picture user has to re-identify this picture in a set of pictures User chooses set of places in a picture user has to click on each place Issues similar to text-based passwords arise e.g., choice of places is not necessarily random Shoulder surfing becomes a problem CS 450/650 Lecture 19: User Authentication

Graphical Passwords CS 450/650 Lecture 19: User Authentication

Server authentication With the help of a password, system authenticates user (client)‏ But user should also authenticate system (server) so that password does not end up with attacker instead! CS 450/650 Lecture 19: User Authentication

Server authentication Classic attack: have a program display a fake login screen when user “logs in”, programs prints error message, sends captured user ID and password to attacker and ends current session which will start actual login screen That’s why Windows requires you to press <CTRL- ALT-DELETE> for login Always gives login window and cannot be overridden Today’s attack: Phishing CS 450/650 Lecture 19: User Authentication

Biometrics Authenticate based on physical characteristics Fingerprints, iris scan, voice, handwriting, typing pattern,… Biometrics have been hailed as a way to get rid of the problems with password and token-based authentication Unfortunately, they have their own problems CS 450/650 Lecture 19: User Authentication

Biometrics If observed trait is sufficiently close to previously stored trait, accept user Observed fingerprint will never be completely identical to a previously stored fingerprint of the same user Biometrics work well for local authentication, but are less suited for remote authentication or for identification CS 450/650 Lecture 19: User Authentication

Local vs. Remote Authentication In local authentication, a guard can ensure that: I put my own finger on a fingerprint scanner, not one made out of gelatin I stand in front of a camera don’t just hold up a picture of somebody else In remote authentication, this is much more difficult CS 450/650 Lecture 19: User Authentication

Authentication vs. Identification Authentication: Does a captured trait correspond to a particular stored trait? Identification: Does a captured trait correspond to any of the stored traits? a search problem, which is made worse by the fact that in biometrics matches are based on closeness False positives can make biometrics-based identification useless False positive: Alice is accepted as Bob False negative: Alice is incorrectly rejected as Alice CS 450/650 Lecture 19: User Authentication

Biometrics-based Identification Example (from Bruce Schneier’s “Beyond Fear”) Face-recognition software with (unrealistic) accuracy of 99.9% is used in a football stadium to detect terrorists 1-in-1,000 chance that a terrorist is not detected 1-in-1,000 chance that innocent person is flagged as terrorist If one in 10 million stadium attendees is a known terrorist, there will be 10,000 false alarms for every real terrorist CS 450/650 Lecture 19: User Authentication

Other Problems with Biometrics Privacy concerns Why should my employer (or a website) have information about my fingerprints, iris,..? Aside: Why should a website know my date of birth, my mother’s maiden name,… for “secret questions”? What if this information leaks? Getting a new password is easy, but much more difficult for biometrics Accuracy: False negatives are annoying What if there is no other way to authenticate? What if I grow a beard, hurt my finger,…? CS 450/650 Lecture 19: User Authentication