Lecture 17:

Introduction to Security: Authorization

Scribe Notes Prepared by Daniel Baldonado


Index

  1. NFS Security
  2. General Security Principles
  3. Threat Modelling and Classification
  4. Authorization
  5. Permissions
  6. Reflections on Trusting Trust

Audio from Lecture

Download Audio: M4A


NFS Security

Man in the Middle Attacks

A man-in-the-middle attack occurs when a snoop eavesdrops on a connection by making independent connection with the victims and relays messages between them. To protect against these attacks, we can encrypt packets, but this costs time. Thus, it is more popular in practice to use private networks.

Password Name vs uid Mismatches

When logging in from multiple clients, the user may have mismatching uids in the different clients. Thus, even in the same network, the user would be re-authenticated to gain access. Thus, there needs to be a way for secure network authentication.

Client Could Spoof a Server

A malicious can pretend to be a server, tricking other clients. One of the more popular ways of comabtting this is using Kerberos Authentication.

Go To Top

General Security Principles

In the non computing world, we must defend against attacks. There are two main types of attacks and one second order type that are most common:

Force:

For example, when someone pulls a gun out on you.

Fraud:

For example, when someone steals your banking information and uses your information to steal your money.

Snooping:

For example, when someone watches you through your window to see what you are doing. This attack may be considered second order.

However in the computing world, we tend to worry mostly on fraud and then secondarily on snooping. With that said, there are three typical Computer Security Attacks that we have to protect ourselves against:

Privacy

Example: Unauthorized information release, including passwords and other sensitive information

Integrity:

Example: Tampering of data, including deletion of files, changing grades, and other unwatned actions

Service:

Example: Denial of Service attack, an attempt to make the machine or resource unavailable to all users

General Goals in Building a Secure System

When building a secure system, there are three main goals we want to meet:

Deny Unauthorized Access

Protects against Privacy and Integrity attacks

Allow Unauthorized Access

Also protects against Privacy and Integrity attacks.

Operate efficiently enough even in presence of Denial of Service Attack

Protects against Service attacks

How do we know that these test goals are met?

The hardest part of building our secure system is testing that our three main goals are met. We can relatively easily create tests to ensure that we allow unauthorized access. However, testing becomes hard to do for denying authorized access and operating efficiently. How are we going to know all the possible ways a malicious user could get past our denial of access? How often do we test efficiency at the presence of a Denial of Service attack? Even if the tests were run often, the test attack may not even be as big as a potential attack.
Go To Top

Threat Modeling and Classification

The first step in the design process for security is defining possible threats by looking at possible use cases that may be exploited for malicious actions.

Common Security Threats

Insiders

Insiders are people who are inside the system, but have gone bad. For instance, a retiring professor may have had access to other classes' grades. Leaving with a bad note with the university, he decides to change the grades of random students in other classes. This would be considered an insider attack. This is the main threat for many systems.

Social Engineering

Social engineering is the art of manipulating people into performing actions and/or divulging confidential information. One example of this happening would be Kevin Mitnick, widely considered the most infamous hacker in Los Angeles history. Kevin's hacking specialty was considered to be phone systems, stealing long distance calls and listening to other people's conversations. How did he do this? Kevin simply called the phone system and asked for the password to the telephone pole near his victims. The support line on the other end knew Kevin was at the telephone pole from his request, so they assumed he was a repairman who needed the password for a repair. Surprisingly enough, this type of attack is fairly common and successful.

Network Attacks

Worms and viruses are two well-known types of network attacks. The network attacks that are most popular now are drive-by downloads. Drive-by downloads offten occur by an unsuspecting victim viewing a malicious website or email-adress and/or by clicking on a misleading pop-up window/advertisement. Some ways people try to circumvent these attacks are disabling javascript entirely or with browser extensions such as No Script. Denial of Service attacks also fall under network attacks.

Device Attacks

Device attacks include USB viruses and viruses on other external devices. For example, usb drives with viruses may be left on the floor for unsuspecting victims to pick up and connect to a computer.

General Security Functions

The following functions are needed to defend against the common security threats. All of the functions work together to fight these attacks.

Authentication

Authentication checks to see if the user is who they say there are. Passwords are assumed to suffice for authentication: if you have the correct password, you are who you say you are.

Intgrity

We must ensure that data is not tampered with. To do this, we use a checksum to reassure the data is not changed.

Authorization

Assuming we have solved the authentication problem (with the password), we must now authorize the user to only do certain things. We do this with permissions (read, write, execute). More on permissions later, in the authorization section.

Auditing

To clean up and diagnose attacks after they have happened, access logs are used to analyze the attack.

Constraints

Efficiency

When implementing our security, we have to do everything such that it doesn't slow down too much. But how much is too much?

Correctness

We must ensure that our system works correctly. Must account for abstraction and modularity.

Go To Top

Authorization

There are two major ways to access resources.

Direct

With diect access, we map into the address space. Here, we can use ordinary loads and stores. Each access is checked by hardware. However, when you get a fault, a fault handler is under software control, so you can do fancier things. This is the faster method, but it is not very extendible.

char *p = mmap(fd,offset, size, ...)

Indirect

With indirect access, we don't map into address spaces, but hace service requests via handles (opaque objects). Unlike direct access, each request is handled by software. Thus, indirect access leads to lots of flexibility and finer grained control.

fd = open(file, ...)
read(fd, ...)

Authorization Technology/Method 1: Access Control Lists (ACLs)

Three Dimensional Array

We can store the permissions in a three dimensional array. However, this takes up a lot of bits. To combat the bit usage, we could group together files, users, and even accesses.

for each user:
    for each file:
        for each type of access network(r,w,...):
            check if allowed

Two Dimensional Array

The UNIX approach to authorization involves a two dimensional array in which each file contains a list of user/permissions.

for each file:
    look at list of user/permissions

$ getfacl

The getfacl command displays the file name, owner, the group, and the ACL. Notice below the extra permissions for the user das and the group tas. This helps with scaling and sharing at larger levels, but is more complicated.

$ getfacl
user: rwx
user:das: r-w
group: r-x
group: tas: rwx
other: r-x

Authorization Model

- Capture Rights Accturately
- Ordinary user can specify rights
- ACLs in large organizations aren't flexible enough'

Role based access is better for large organization. For role based access, the user can assume a role for each access. This prevents a malicious user from gaining complete control.

Authorization Technology/Method 2: Capabilities

With capabilities, each file descriptor lists permissions in contrast to ACLs where each file lists permissions.
fd = open("xabc", O_RDONLY)

Can we have a file descriptor with no rights?

With Standard POSIX? No. With recent versions of linux? Yes, using O_PATH. This can be used for methods such as fstat(...) to find the owner of the file or when it was last modified.

Can we have a Capabilities only system?

Yes, we have a directory map(names->capability). We can clone capabilities and take permissions away. This works even across a network. But how do we prevent forged capabilities? We use encryption.
Go To Top

Permissions

$ ls -l
-rwsr-xr-x ... 

What is the s?

How is it possible to get an s when it is represented by a single bit indicating if there are execute permissions? There are three hidden bits before the well know "755" bits. These three bits are represented by the setuid, setgid and sticky bits (in order). A 4755 would cause the s to appear and likewise a 4655 would cause a capital S. What does this mean? If the setuid is set, upon execution of the program, the program runs as the owner of the file. An example of this would be /bin/passwd. This avoids the need for daemons.

What needs to be trusted

Daemons running as root must be trusted. Other code that must be trusted include: /bin/passwd, login, device drivers, kernel. It is ideal to keep the list of code that has to be trusted as small as possible. We want things like gcc, emacs, oracle, mysql, etc. to be outside of the TCB, the Trusted Computing Base.

Go To Top

Reflections on Trusting Trust

Ken Thompson, who implemented the original Unix system, reflected on how one trusts the packages shipped out by the makers of operating systems. When creating Unix, Thompson could have inserted a special code in login.c to allow him to login to any Unix machine.
if(strcmp(user,"ken")==0)
    uid = 0;
However, this code can be easily seen and questioned. Thus, he could have generated the code in the compiler, CC:
if(compiling(login.c))
    generate strcmp
This code can be seen easily, too. So what if he inserted code when compiling CC itself to generate the CC code. This process could continue, hiding the inserted code. Ken Thompson didn't actually do this, but the question is remains: how do we know that this does't exist in Windows or Unix or any other system we use?
Go To Top