1. Lecture 18 Overview

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

3. 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

4. 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

5. 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

6. 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

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

8. 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

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

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

11. 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

12. 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

13. 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

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

15. 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

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

17. 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

18. 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

19. 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

20. 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

21. 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

22. Directory
CS 450/650 Lecture 19: Access Control

23. 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

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

25. 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

26. 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

27. 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

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

29. 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

30. 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

31. 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

32. 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

33. 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

34. 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

35. 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

36. 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

37. 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

38. 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

39. 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

40. User Authentication
CS 450/650 Lecture 19: Access Control

41. 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

42. 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

43. 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

44. 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

45. 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

46. 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

47. 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

48. 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

49. 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

50. 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

51. 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

52. 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

53. Password Hygiene Don’t reveal passwords to others
In 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

54. 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

55. 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

56. 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

57. 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 password to predefined address when user forgets password
Has become the norm for many websites

58. 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

59. 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

60. 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

61. Graphical Passwords
CS 450/650 Lecture 19: User Authentication

62. 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

63. 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

64. 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

65. 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

66. 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

67. 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

68. 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

69. 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