CS 111 – Lecture 18

Security Problems: Authentication and Authorization

Scribed by
Steven Beck

Authentication

How to authenticate

This presents a bootstrapping problem: How can you establish your initial SEASnet password?
Go to the office and show your BruinCard. But how did you authenticate for your BruinCard? Etc...

External vs Internal Authentication

Example

External

Properties:
  1. Stricter checking
  2. Slower
  3. Must not be guessable
  4. Should be easy to remember
How can we, enforce the last two a the same time? If the OS supplies a password for the user, it is hard for others to guess but not easily rememberable for the user.
One good approach is for the OS to checks/enforce certain strength of passwords. The user can now create a memorable password too complex for others to guess.

Internal authentication

Possible Attacks

External

Dictionary Attack
Try common passwords until one works
Defense: limit number of attempts
Social Engineering Attack
Trick someone into revealing their authorization (e.g. password, key, etc.)
Defense: don't rely on "knows" or "has" authorization.
Sysadmin Attack
Admin leaves backup of passwords on drives and leaks them (incompetence)
Defense:
Rainbow Attack
Given a file with a set of encrypted password: Guess password, encrypt it, compare to those in file
Defense: salt password by adding randomly generated bits to end of password. Encrypt salted password and store this in the file. The length of the salt should support more variations than the total number of users. Salting slows attackers down because the attacker would have to try each guess with all salt possibilities.
Snooping Attack
E.g. keystroke logging or video surveillance in an airport
Defense:
Fake Server Attack
Either with a creatively named website (e.g. Google.cm) or an infected router or some other means, webpages can be replaced by fake pages that will steal your information.
Defense: Two-way authorization where the server also authenticates to the client that its safe (e.g. trusted image, secret number established upon first login, or certificates signed by trusted authority)

Internal

Background: In Unix, this is done via process table with uid (user) and gid (group). These ids are consulted for access decision. File access is logged.
Possible issue: Should we have a new system call setuid(u,g)? There is one, and it operates under the following conditions:

  1. Fails unless current id == 0 (root user)
    But what about the following example?
    $ su
    Password: <enter root password>
    # rm -rf /
    How did we get to the last line above if condition 1 is true? Answer: there is one more conditions:
  2. If an executable has the setuid bit ON in its mode, executing it gives the process the file's uid
    ___rwxr-xr-x
     4  7  5  5
     ^setuid bit before rwx bits
In this way, setuid programs provide protective transfer of control as discussed earlier in the course.
Attack 1:
$ cp /bin/sh /bin/su
This gets the special bits that are set for /bin/su to be used for our shell instead
Defense: OS disallows this. Result is "permission denied" because only root can write for these files.
Attack 2:
Boot A as root, mount B, modify B however you'd like.
Attack 3:
$ ls -ld /bin
drwxrwxrwx
Attack 4:
$ mv /bin/su /bin/su.old
$ mv mysu /bin/su

mysu saves pass to a file, then runs su.old. The passwords are now stolen (in the file). The user will never notice since su runs as expected.

Authorization

Authorization deals with who has the right to do what. We can visualize this with a 3-dimensional space.
[Authorization space visualization]
Authorization is the ability to look at any spot in this space and determine if it is allowed. Each point in the space is a boolean value where 1 is permission is granted and 0 is not.

Example:
Principals: 10K users
Resources: 1M files
Actions: 10 (read, write, etc.)
Goal: manage this big (100B) array of booleans in a way that is both compact and fast
In Unix:files and processes have owners(uid) + groups(gid) + modes(12bits) <--- We want to be able to determine which opertions are allowed for each category (self, group, others)
Example:
Eggert creates new dir /u/class/fall14/cs111
Need to give TAs A, B, C rwx access to this dir
Need a new group: cs111tas. But this requires sysadmin privileges. Not going to happen on SEASnet.
Even if we were allowed to do this, it becomes more and more extensive as the number of users, actions, and files grow. To make this structure more compact and more efficient, we approach it with access control lists.

Access Control Lists (ACLs)

ACLs are the standard approach to authorization. It is the idea of granting permission to an entire group of users, where the group can be created only by the root user.

One entry in a file's inode is dedicated to a pointer the the ACL block.
ACL block contains a list of users with permissions for this file.
Think: ACL provides exceptions to the three general rules (user, group, world).

Problem: Add 1M users to ACL?
Solution: Don't do this

Problem: ACL is metadata and needs new system calls to edit
Solution: set/getfacl commands
only file's owner can use these calls to edit ACLs

Problem: Buggy code for a certain program (e.g. grade book) will be able to affect other parts of the filesystem that it shouldn't care about (e.g. salaries). This is because a process inherits all rights of its user.
Solution: Role-based access control (RBAC). The idea of this is that each user has a role, and through that role, they are granted certain permissions to perform actions on specific files/ objects.
This compacts all permissions into a grouping and makes delegating a lot easier and there will be a less likely a chance of accidentally giving someone unprecedented permission.

Capabilities

Capabilities control access to an object by encrypting pointers to the object.
Think: ticket. Once you have this ticket, you are free to access the object according to the associated access rights. No longer need the kernel to enforce protection of objects.
In Unix: file descriptors are sort of capabilities. The main difference is that they are not encrypted, rather the actual info is in the kernel.

Example:
$ (chmod 444 new-file
echo hello
) > new-file

This works because the current file descriptor held by the sub-process has write access. Getting a new file descriptor for new-file would only allow reading.

Capabilites can be shared by anyone.
Newtork sends out capability to client to work with a file.
[Capabilities nework visualization]
This client could share the ticket with others.
But what if we want to prevent this?
Solution: Remember which tickets we sent where and check these when the tickets are used.

For most cases, capabilities add too much complication and therefore are only used when someone cares a lot about security and performance.

Reflections on Trusting Trust by Ken Thompson

We want to modify the login program, to always login "ken" as root. Modify source code of login.c:
if (strcmp(username, "ken") == 0) {login as root}
However, Linux is open source and someone might see the change. So, modify gcc.c instead:
if(strcmp(filename,"login.c") == 0) {generate code for bad login.c}
But someone may now see this change in gcc.c. Create evil_gcc.c instead:
if(strcmp(name, "gcc.c" == 0) {generate code for bad gcc.c}
Now we can compile an evil version of gcc and ship the executable with Linux. Everyone will then compile our evil gcc and evil login, all without us ever shipping a modified login.c or gcc.c
We can do a similar process with gdb to further mask the change in case someone became suspicious.

Ultimately, everyone has to trust a small circle of programs to do what they are supposed to. Try to keep this circle small.