Lecture 18
Access Control
06/01/10
scribe notes by Michelle Auyoung
How do you access resources?
|
direct
~ app. has pointer to OS object
~ access check is done when pointer is given to app. (via VM)
+ fast access after check
- resource more easily corrupted
|
indirect
~ app. gets an opaque handle
(e.g. file descriptor)
- slower access: syscall
+ fine-grained access control
(e.g. remote access)
|
Access control goals
Goals:
- privacy: prohibit reads that aren't allowed
- integrity: prohibit writes that aren't allowed
- trust: get the right program
- sharing: get your work done!
|
Nongoal:
to design:
- threat analysis
- security model
|
Keeping track of what acccesses are allowed
Access control data itself - must be updateable (sensitive op.)
- controlled op. needed
- indirect access, due to sensitivity
Two main ways:
- Access Control Lists (ACLs): accesses to object must go through a guard
- Capabilities: distributed set of keys to object
=> In both cases:
- must be unforgeable (at least, part must live "in" OS)
- must be consulted before access
- HW and/or OS support needed (not just library functions)
Access control models
3-D array of booleans:
to store access control (AC) info =>
|
^ (y-axis)
principals (1e4 bits)
-> (x axis)
all objects (1e6 bits)
/ (z axis)
operations (1e2 bits)
=> 1e12 total bits
|
-
- (who can do what to an object) /
- |
- |
- |
- |
- |
- | | | | | ... | | | | | | | /
|
Unix permissions model - each object has 9 permission bits
ex: ls -l output
rwx rwx rwx
^u ^g ^o
|
(9 bits) + (owner) + (group)
= 9 + 32 + 32
= 73
=> 73e6 total bits
|
+ much more compact (than 3-D array)
+ easy to check
- 3 ops.
|
|
a single process can have several (up to 8) groups simultaneously
|
- a bit too generous in many cases (can access two different groups, but risk modifying groups (overlapping))
- sysadmin (root) is in charge of group membership => inflexible
- hard to maintain (lots of people and lots of roles)
|
ACLs
(Windows NT) -> now in Linux, Solaris
~ associated with each file is a list of users (+ groups + ops) that can access it
$ getfacl
user::rwx
group::r-x
adnan::rwx
other::---
$ setfacl rwxr-x---
^ This fixes the problem of only root being in charge of group membership
Role Based Access Control (RBAC)
(used in Solaris, Active Directory)
~ users can assume roles
- rights are associated with roles
- if you assume a role (employee, instructor-in-charge, student), you may lose rights of a previous role
- you can have (> 1) sessions with different roles
- often comes with fine grained control over ops.
- e.g. unlink(d) - normally not allowed
use rmdir(d) instead
- e.g. link to a file you don't own
link("/user/adnan/a", "b") - normally ok
- security hole - hard links can bypass permissions made after link created
$ ls -l /bin/passwd
-rwsr-xr-x root /bin/passwd
$ ln /bin/passwd $HOME/p
(fix security hole in passwd program)
# cat fix > /bin/passwd.new
# chmod 4755 /bin/passwd.new
# mv /bin/passwd.new /bin/passwd
=> fix in the passwd program is not reflected in the old passwd program the attacker already saved (by creating the hard link to it)
Capabilities
(word that points to an object)
~ possession of this "word" implies rights to object
[ encrypted checksum (not forgeable) ] <-- word
~ process can email it
- How to implement:
- encryption - capabilities can be sent across net --> Process 1: fd = open(), then can 'send' fd to Process 2
- index into OS table (e.g. file descriptor) <-- can you forge these? No: you must use 'open'
- Issues:
- word must be wide enough to not be guessed (at least 64 bits)
- containment - capability can escape (e.g. if you log it) - big problem - why most people don't use capabilities
Denial of service attacks
~ attacker visits whitehouse.gov/feedback --> add comment: Prez is dope! --> does this 1000000 times