1. Authentication & Access Control

2. Security Countermeasure
What do we really need?
From user perspective
From process/thread perspective
From file/directory/file system perspective
From memory management and other I/O device perspective
From service perspective
From network perspective ……

3. What we need in term of security?
Authentication
Username/Password
One-time Password
Smartcards/Activebadge
Biometrics
Access Control
User-based
Role-based
Location-based
Separation/Interaction, Multi-level Security
Data Confidentiality & Integrity
Encrypted file
Encrypted file system
Service/system availability/reliability
Redundancy: RAID, Multi-Core, etc.

4. History of Secure OSes Multics UNIX/Windows Security
Security Kernels/TCB/SELinux
Microkernels/MicroVM
TPM
System Assurance
Orange Book
Common Creitera

5. Case Studies UNIX Password Unix/Linux Access Control
Users and groups
File system controls
(HW) Windows NT/XP Security Executive
Access tokens
Security descriptors
ACLs
(HW) Windows Vista
Security additions

6. Unix Reading Material Man pages
Groups, newgroup
Chmod, chown, chgrp
Unix and Security: The Influences of History
ftp://coast.cs.purdue.edu/pub/doc/misc/spaf-influences-of-history.ps.Z

7. Basic Unix Security Model
User authenticated on logon
User ID associated with process
Default Group ID associated with process
Default Process listed in passwd file
Groups defined in /etc/groups
Set of users listed with each group definition
User can be member of multiple groups

8. Passwords in UNIX Login: guan Password: cpre308
How does the system check if the password is correct?
One solution:
Password file has (username, password) pairs
Store [guan, cpre308] in /etc/passwd
Password file readable only by privileged user
Privileged users can get your password
Why is this a problem?

9. Solution: One-Way Functions
f(x) is easy to compute
f -1(x) is extremely difficult, if not impossible, to compute
Password file can now be world-readable
Unix password file contains image of each password
/etc/passwd contains guan:y
guan logs in, supplies x
if f(x) == y, then ok
How to deal with the verifier is an issue even in non-distributed systems. Unix, and many other systems, authenticate users by having them supply their passwords. Rather than keep the plaintext of the passwords a file where they might be seen by others, Unix stores encrypted passwords, as described in the slide. Much of our discussion on cryptology-related concerns comes from Applied Cryptography, 2nd Edition, by Bruce Schneier, John Wiley and Sons, 1996.
Copyright © 2002 Thomas W. Doeppner. All rights reserved.

10. Dictionary Attack (Morris and Thompson)
For all words in dictionary, compute f(word)
Find word such that f(word) == y
Many users use simple passwords
Systems that employ just one-way functions to protect their passwords are vulnerable to dictionary attacks.
Systems that employ just one-way functions to protect their passwords are vulnerable to dictionary attacks.

11. Counterattack Salt for each password, create random “salt” value
/etc/passwd contains (f(append(word, salt)), salt)
12-bit salt values in Unix
attacker must do dictionary attack 4096 times, for each salt value
done …
Feldmeier and Karn produced list of 732,000 most common passwords concatenated with each of 4096 salt values
covers ~30% of all passwords
Unix uses “salt” as a means to foil dictionary attacks, though it’s probably not of tremendous use anymore.

12. Shadow Files
/etc/passwords and /etc/group must be readable by everyone
Both files contain crypt’ed passwords
Access enable offline attacks
Add shadow versions of each file
Password obscured in passwords and group
Stored in more restricted shadow versions of these files

13. Authnetication

14. Overview Authentication is to prove the identity of a user
Four categories
Something you know
Something you have
Someone you are
Someone you know

15. Something you know
Password
Security questions

16. Passwords The most popular authentication method
Security & Usability issues
Long and random passwords are harder to remember
Users select memorable passwords, which are easy to guess
Users reuse passwords across multiple devices/websites

17. Attacks to Passwords Online guessing attacks
Social engineering and phishing
Eavesdropping
Client-side malware
Server compromise

18. Online Guessing Attacks
Repeatedly try logging in with many different guesses
123456
password
Defenses
Rate limiting, e.g., 5 guesses in one day
CAPTCHAs
Vulnerable to machine learning attacks
Underground markets hire human workers to solve CAPTCHAs

19. Social Engineering and Phishing
Fool a user to reveal his/her password
Defenses
Educating users
Machine learning to detect phishing sites

20. Eavesdropping
If plaintext passwords are sent from the client to the server, they can be eavesdropped on internet, e.g., public Wi-Fi.
Defenses
Encryption!

21. Client-side Malware Keyloggers to capture passwords Virtual keyboard
Malware records the locations of mouse clicks and take screen shots
Very difficult to defend in this threat model

22. Server Compromise Get a copy of the password database
32M passwords from Rockyou in 2009
Do not store user passwords in plaintext
Use cryptographic hash function and salt
Store (username, salt, H(salt, password))
Offline password guessing: test guesses on the attacker’s own computer
Use slow hash function to slow down offline password guessing

23. Security questions “What color do you like” “Where is your hometown”
Social knowledge
E.g., “Who you exchanged private messages on Facebook in the last week”.
Security and usability problems
Some users forget their own answers
Partially because they use fake answers according to a recent study performed by Google researchers
Some answers are easy to guess
Insecure

24. Something you have Hardware token Software token E.g., RSA SecurID
Private key in a public-key cryptosystem
OpenSSH

25. Someone you are-biometrics
Fingerprint
Iris
Voice
Face
Keystroke dynamics
Touch-based behavioral biometrics
Used on mobile devices
How you walk?

26. Biometrics Pros Cons Convenient, users do not need to bring anything
Users cannot change them.
E.g., once fingerprint gets stolen. The attacker can do everything
What if a user’s finger is wounded

27. Someone you know-social authentication
Facebook
Microsoft
Select m trustees
Used for password reset
Alice

28. Social Authentication
Service Provider
k: recovery threshold
Very reliable 6 5 1
Secure when
carefully designed
Security codes
k security codes
Recovery request
Password reset 2 3
Request security code
Very reliable
[Schechter et al. 2009] 4
Share security code
Trustees
Alice

29. Multi-factor authentication
Combine multiple sources to verify identity
Examples
Password + hardware token
Password + security questions

30. Access Control

31. Review: The File Abstraction
A UNIX file is a simple array of bytes
Files are made larger by writing beyond their current end
Files are grouped into directories
As discussed three pages ago, most programs perform file I/O using library code layered on top of kernel code. In this section we discuss just the kernel aspects of file I/O, looking at the abstraction and the high-level aspects of how this abstraction is implemented.
The Unix file abstraction is very simple: files are simply arrays of bytes. Many systems have special system calls to make a file larger. In Unix, you simply write where you’ve never written before, and the file “magically” grows to the new size (within limits). The names of files are equally straightforward—just the names labeling the path that leads to the file within the directory tree. Finally, from the programmer’s point of view, all operations on files appear to be synchronous—when an I/O system call returns, as far as the process is concerned, the I/O has completed. (Things are different from the kernel’s point of view, as discussed later.)

32. Review: Directories unix etc home pro dev motd twd unix ... slide1
passwd
motd
twd
unix
...
Here is a portion of a Unix directory tree. The ovals represent files, the rectangles represent directories (which are really just special cases of files).
slide1
slide2
Copyright © 2002 Thomas W. Doeppner. All rights reserved.

33. Review: Interface to the Programmer
1. Open a file (read, write, read-write) modes
fd = open("file", O_RDONLY);
2. Read/Write the file
size = read (fd, buffer, n);
size = write(fd, buffer, n);
3. Close the file
close(fd);

34. Review: File Access Control
Who’s allowed to perform what actions on a file?
Each file has associated with it a set of access permissions indicating, for each of three classes of principals, what sorts of operations on the file are allowed. The three classes are the owner of the file, known as user, the group owner of the file, known simply as group, and everyone else, known as others. The operations are grouped into the classes read, write, and execute, with their obvious meanings. The access permissions apply to directories as well as to ordinary files, though the meaning of execute for directories is not quite so obvious: one must have execute permission for a directory file in order to follow a path through it.
The system, when checking permissions, first determines the smallest class of principals the requester belongs to: user (smallest), group, or others (largest). It then, within the chosen class, checks for appropriate permissions.
Copyright © 2002 Thomas W. Doeppner. All rights reserved.

35. Access Control Some resources (files, web pages, …) are sensitive.
How do we limit who can access them?
This is called the access control problem

36. Access Control Fundamentals
Subject = a user, process, …
(someone who is accessing resources)
Object = a file, device, web page, …
(a resource that can be accessed)
Policy = the restrictions we’ll enforce
access(S, O) = true
if subject S is allowed to access object O

37. Access control matrix [Lampson]
Subjects
Objects
File 1
File 2
File 3 …
File n
User 1
read
write -
exe
User 2
User 3
User m

38. Two implementation concepts
File 1
File 2 …
User 1
read
write -
User 2
User 3
User m
Read
Access control list (ACL)
Store column of matrix
with the resource
Capability
User holds a “ticket” for
each resource
Two variations
store row of matrix with user, under OS control
unforgeable ticket in user space
Access control lists are widely used, often with groups
Some aspects of capability concept are used in many systems

39. ACL vs Capabilities Access control list Capabilities
Associate list with each object
Check user/group against list
Relies on authentication: need to know user
Capabilities
Capability is unforgeable ticket
Random bit sequence, or managed by OS
Can be passed from one process to another

40. Roles (also called Groups)
Role = set of users
Administrator, PowerUser, User, Guest
Assign permissions to roles; each user gets permission
Role hierarchy
Partial order of roles
Each role gets
permissions of roles below
List only new permissions
given to each role
Administrator
PowerUser
User
Guest

41. Role-Based Access Control
Individuals
Roles
Resources
engineering
File 1
File 2
marketing
File 3
human res
Advantage: user’s change more frequently than roles

42. Reference Monitor
A reference monitor is responsible for mediating all access to data
Subject cannot access data directly; operations must go through the reference monitor, which checks whether they are OK.
Reference Monitor
Object
Subject

43. Unix File Access Control
Subject
Users(owner, group, others)
Object
Directory/File
Actions
read
write
execute
Each file has associated with it a set of access permissions indicating, for each of three classes of principals, what sorts of operations on the file are allowed. The three classes are the owner of the file, known as user, the group owner of the file, known simply as group, and everyone else, known as others. The operations are grouped into the classes read, write, and execute, with their obvious meanings. The access permissions apply to directories as well as to ordinary files, though the meaning of execute for directories is not quite so obvious: one must have execute permission for a directory file in order to follow a path through it.
The system, when checking permissions, first determines the smallest class of principals the requester belongs to: user (smallest), group, or others (largest). It then, within the chosen class, checks for appropriate permissions.
Copyright © 2002 Thomas W. Doeppner. All rights reserved.

44. Permissions Example % ls -lR .: total 2
drwxr-x--x 2 snt adm Dec 17 13:34 A
drwxr snt adm Dec 17 13:34 B
./A:
total 1
-rw-rw-rw- 1 snt adm Dec 17 13:34 x
./B:
-r--rw-rw- 1 snt adm Dec 17 13:34 x
-rw----rw- 1 trina adm Dec 17 13:45 y
Show an example, man, ls, chmod
Copyright © 2002 Thomas W. Doeppner. All rights reserved.

45. Setting File Permissions
#include <sys/types.h>
#include <sys/stat.h>
int chmod(const char *path, mode_t mode)
only the owner of a file and the superuser may change its permissions
nine combinable possibilities for mode (read/write/execute for user, group, and others)
S_IRUSR (0400), S_IWUSR (0200), S_IXUSR (0100)
S_IRGRP (040), S_IWGRP (020), S_IXGRP (010)
S_IROTH (04), S_IWOTH (02), S_IXOTH (01)
Symbolic mode
Chmod o-x file
Copyright © 2002 Thomas W. Doeppner. All rights reserved.

46. Access Control Models Lampson’s Access Matrix Reference Monitor
A secure OS is the one that satisfies:
Complete Mediation
TOCTTOU (Time-of-Check-to-time-of-use)
Tamperproof
Verifiable
Assessment Criteria

47. Verifiable Security Goals
Information Flow
IF Secrecy
Denning’s Lattice Model
Bell-LaPadula Model
IF Integrity
Biba Integrity Model
Low-water Mark Integrity
Clark-Wilson Integrity
Covert Channels