CS 111: Lecture 18 Scribe Notes (12/8/2014)

Authentication and Authorization

by Arthon Charanvattanakit

Authentication

Three main ways of authentication based on information of an entity (principal)

1. Who the principal is
Example: Retinal scan, brain scan
2. Something the principal has
Hardware token that's hard to reproduce
Example: Physical key
3. Something the principal knows
Example: Password

It's usually better to combine methods than using just one. For example, if a principal needs both a password and a physical key to login, there's a much lesser chance of an unauthenticated user gaining access.

Bootstrapping Issues

UCLA student wants a SEASnet account but they need a Bruincard to make one. Then they need to look like the picture on the card, etc.

External vs. Internal Authentication

There are two types of authentication: external and internal.

External

External authentication involves principals trying to enter the system from outside.

Example: A principal trying to gain access at an army base must be authenticated by a guard at an entrance gate.

External authentication tends to be slower and more expensive than internal authentication. External authentication is usually done with a login agent inside the OS talking to the outside, like asking the principal for a password. Passwords must not be guessable by nonauthenticated users but should also be easy to remember for the principal. There are multiple types of attacks against password authentication and corresponding defenses mechanisms.

Attacks

Defenses
Using a common password dictionary until the password is found. Limit the number of attempts at logging in. Lock a user out if they use the wrong password several times.
Social engineering. Someone asking to "borrow" a password Don't rely on "has" or "knows" authentication. Someone could have borrowed this information, but "who" authentication can prevent it.
Sysadmin leaking passwords Require users to change their password reguarly. Using encryption to secure passwords with a salt. If a password is "H?o3j\Ac", add a random salt and encrypt that to slow attacker down. Encrypt "H?o3j\AcxJB"
Password snoopers, such as a camera at an airport watching people put in their passwords Encryption between client and server, cryptographic protocol
Fraudulent servers Server authenticates to the client. Perhaps via images, or certificates signed by a trusted authority.

Internal

Internal authentication is getting authenticated from inside. Back to the army base example, once externally authenticated and walking around, guardsmen inside will authenticate you. Internal authentication is done every time a principal wants to access Something, thus it must be cheap and fast.

In Unix, internal authentication is done via a process table entry. Process table entry

Internal authentication uses these process table entries, using the user id (uid) and group id (gid). These records are consuted for access decisions and logged in an access log.

setuid  setgid
replaces uid and gid. Fails unless current uid == 0. Files have a setuid bit which when set, will run with user and group permissions set by its owner. For example if a file's owner is root and its setuid bit is set, the file will run as root.

A potential exploit of setuid:

$ cp /bin/sh /bin/su

If a user successfully does this, they could potentially run sh with the setuid bit set, running sh as root.

Authorization

Keeping track of what users are allowed to do

Authorization cube

Each point in the cube represents the authorization of a user to do a certain action on a certain file. In other words, every point in the cube is a boolean value. Example: User - user1, File - a.txt, Action - read. We should know yes or no.

We want to represent this cube compactly and fastly. One approach that comes to mind is to just have a really large array, but this is just too big.

The Unix way

Files have owners (uid), groups (gid), and modes (12 bits) which allow operations for each category. Processes have owners and groups.

Example

Dr. Eggert creates a directory

/u/class/fall14/cs111

TAs A, B, and C should be given rwx access and everyone else should be given r-x. Dr. Eggert should make a group CS111ta with drwxrwxr-x- owned by eggert.

Access Control Lists (ACLs)

Each object has a list of access rights (ACL). Elements in the list consist of a user/group and its permissions. Need system calls

Example

A -> rwx | B-> r-x

setfacl and getfacl can be used to set and get file ACLs respectively.

Example

getfacl file
will tell us the owner, group and permissions of file

setfacl -m u:me:rw file
will give read and write permissions to me for file.
Catches with ACLs

Capabilities

Control access to an object by encrypting pointer to object and other things

In Unix

Keep a record for each process and which objects it can access. Similar to file descriptor (keep actual info in kernel)

Issues

A client might have the ability to forge a capability. This is why long capabilities should be used in followed by encryption.

Trusted Software

How can you trust the system you're running on?

Ken Thompson Attack on Unix

Ken Thompson was a principal inventor of Unix who wrote a paper "Reflections on Trusting Trust" that discussed how people can trust the system they're running on. If he wanted to, he could have inserted code into login.c that granted him root access.

In login.c:

if (ok || username == "ken")
    uid = 0;

However, users can just read the source code and eventually find this.

Instead, modify gcc. Or modify whatever compiles gcc, etc.

evil-gcc.c:

if compiling login.c
    generate machine code for evil-gcc.c

eviler-gcc.c:

if compiling login.c
    generate evil code
if compiling gcc.c
    generate eviler-gcc.c

Valid HTML 4.01 Transitional