Lecture 18 Scribe Notes

By: Nima Rahnemoon

Unix Permissions Model

Each object has 9 permission bits

+ owner (32 bits)

+ group (32 bits)

Advantages

+ Much easier/more compact

+ Easier to check

Disadvantages

- Only 3 ops (read, write, execute)

- Single process can’t be in multiple groups at the same time

Berkeley Unix Permissions Model

- A single process can have several (up to 8) groups simultaneously

Disadvantages

1. A bit too generous in many cases, because you sometimes might not want people to have access to two object simultaneously

2. You need to contact the sysadmin if you want to handle growing membership

3. Hard to maintain (lots of people, lots of roles)

ACLs – Access Control Lists (from Windows NT and now in Linux and Solaris)

Associated with each file is a list of user (+groups) that can access it and the operations each user has access to.

facl: file access control list

$ getfacl

User: rwx

Group: r-x

Adnan: rwx

Other: ---

$ setfacl // Same things except sets it

Nice way of doing ad-hoc system access control.

Role Based Access Control (RBAC) … used in Solaris Active Directory

- User can assume roles

o Rights are associated with roles

o If you assume a role you might lose rights you had in a previous role

o Can have multiple sessions active with different roles

o Often comes with fine-grained control over operations

§ E.g. unlink (d) – normally not allowed

rmdir (d) – is allowed

where d is a directory

§ Under role based access control even unlink (d) might be allowed for certain roles

§ E.g. link to a file you don’t own

link(“user/adnan/a”,”b”);

Unsafe because if you later try to deny access to the user, they still have a link and can search your files.

How do you access resources?

- Direct:

o An application has a pointer to the O.S. object

o Access check is done when the pointer is given to the application

§ Often done by using Virtual Memory

Advantages

§ Fast access after check

Disadvantages

§ Resources can be more easily corrupted

- Indirect:

o Application gets an opaque handle (e.g. a file descriptor)

Advantages

§ Fine-grained access control (e.g. you can revoke access)

Disadvantages

§ Slower access, because every time you want to access memory you have to use a syscall

Access Control Goals (assuming you’ve been authenticated what can you do)

Privacy:

is read allowed?

Integrity

is write allowed?

Trust

do you have the right code?

Sharing

Get your work done!

Non-goal: DOS defense

- To design access control you need:

o To have threat analysis

o A security model

- Keeping track of what access are allowed

o Access control data itself must be updatable (sensitive, because someone can give access to anyone)

§ Controlled operation needed

§ Indirect access, due to sensitivity

- Two main Ways

o Access Control Lists (ACLs)

o Capabilities

o In both cases:

§ Must be unforgable (at least part of it must “live”)

§ Must be consulted before access

§ Hardware and/or OS support needed

Access Control Model

- 3-d array of Booleans telling whether or not a principal can access an object within a given operation.

- This is a terrible model!

Capabilities

- Possession of this word implies the rights to the object

o Encrypted checksum with is not forgeable (kind of like a key which opens permissions to an object)

- You can even email it!

How to implement:

1) Encryption – capabilities sent across the network

2) Index into OS Table (e.g. file descriptor)

e.g. fd = open

then you can send the fd to process 2

Requirements:

1) Must be wide enough to not be guessed.

2) Containment: capability can escape e.g. if you log it.

Denial of Service (DoS) attacks

- Attacker visits : “whitehouse.gov/feedback” and adds the comment: “prez is dope”

o He does this from a million botnet computers which he owns

Defenses

- Captcha

- Log IP address

- Make your server faster….

o Ways to make your server faster

§ Fork requests

· Too slow because you have to copy stack data

§ Multithread requests

· Faster, but a bug in one handler can corrupt the whole system

§ Pre-forked children

· Child handles requests but already exists

§ Event-based I/O (fastest web servers use this)

· Non-blocking I/O

· Multithreaded (1 thread per CPU)

· Threads never block (applications do their own scheduling)