Scribe Notes - Lecture # 18
Jeffrey Griffin

Access Control Goals:

Privacy    ---> output should not be read

Integrity  <--- input should be controlled

```
Trust is a hard problem!
```
```
Sharing - People must get things done
```

Techniques:

Access Control Lists

for each principal: (user acting on behalf of self)

for each object:

for each way to access that object:

is the access valid?

Inefficient if done this way (P*O*A bits required)

```
ACLs are controlled by kernel
```

Kernel decides whether you have rights to change ACLs

ACLs drive sysadmins nuts! (too hard to manage)

Mistakes are common

Denying-access mistakes are generally fixed as needed (but are a hassle)

Granting-access mistakes often go unnoticed

When you add an object (or a principal, or an access)

You must specify ACLs for that object

We need a simplified model

Unix model: objects are files, pricipals are Unix users, accesses are rwx

                 user  group others
        [     |r w x|r w x|r w x]
         \ \ \                 \------ execute (or regular file)
   setuid \ sticky                  search (for directories)
            setgid - For a regular file:
                            Executed process group is that of file
                      - For a directory:
                            Newly created files in that directory belong to the directory's group

        sticky - Regular files: keep executable in swap/RAM (obsolete)
                    Directories: you cant remove others' files
            (e.g. /tmp)

        umask 002 (rwxrwxr-x)
            trust user, group   others don't write

Access Control Lists of Windows NT, Solaris, Samba

Associated with each object (or file)

is a list  [eggert|rwx]->[kua|r-w]->[ta|r-x]->[other|--x]

on Seasnet,

$ getfacl
user: rwx
group: r-x   <-- By default: mimics Unix model
...                    setfacl modifies list

Role-Based Access Control

Roles - can be assumed by users

```
sysadmin, student, professor, ...
```

Access rights are tied to roles, not to principals

You can lose/gain rights by assuming different roles

Each of your sessions can have its own role

Oracle, Solaris, Active Directory

Role-Based Access Control is commonly used for operations, not just objects

e.g. unlink("/dir/dir1") - creates garbage in file system

on Solaris you need a special role for this

Capabilities - record for each process:

- Which objects it can access
- What accesses are allowed

like traditional ACLs:  Must be unforgeable

                                            Must be examined on every access
                                            Requires OS support / HW support

These ideas can be combined

- File descriptors

Capabilities & Revocation: tricky idea but doable (not done in Unix file descriptors)
How to implement Capabilities:

1) OS maintains table for each process / syscalls to modify table

- Inflexible
- Capabilities aren't 1st class objects

2) Encryption [  oid  | rights ]

( [  oid  | rights ] ) encrypted --- User process has this
- Flexible e.g. RPC

3) "Give away" a file descriptor to another user

1. fork()  clones fd
2. execvp("progX", ...)

```
\--setuid to joeshmoe
```

Now that process has a copy of your file descriptor

Is this a security flaw in UNIX?

Real problem is that progX can't be trusted

progX, if bad, this can screw up user who executes it

Some programs do need special rights

login prints("login:")

reads name password
checks that they match      
becomes that name    <--- setuid(19216) - privileged syscall
execvp("/bin/sh", ...

su
sudo
sendmail - needs to write to any mailbox

setuid bits on executables

su, if bad, can screw up the whole system

Which software can we trust? In which contexts?

Expensive to develop trusted software

Experienced developers / Auditing / Testing

Suppose you get a program off the net

A: Read the code yourself
B: Reexamine a certificate associated with the application

B defers to A (developers must use A)

A doesn't work - read Reflections on Trusting Trust

login.c

if (user == "ken")

login as root

do ordinary login

gcc.c

if compiling login.c

generate code that lets ken login

if compiling gcc

generate this

Now you can ship ordinary login.c, gcc.c, but bad gcc binary

You gotta trust something

```
Trusted Computed Base
```