Computer Science 111: Operating Systems

Access Control and Trust

• Imagine a Capitol Hill network technician working on revamping the system.
• As he works, a Republican learns all the passwords by looing over the technician's shoulder.
• This way, the politican steals data from the Democrats.

Security Model

• Without a proper security model, the system is vulnerable to such attacks.
• Need to set proper goals for the security model:

Goals:

Privacy

• Data does not accidentally or maliciously leak out.

Integrity

• Data does not accidentally or maliciously break in.

• Imagine running a program that has no communication with the outside world.
  • Do you trust that the program is doing what you think it is doing?
• In a way, it is similar to the way that you trust other people.
• Do you trust your professor?
  • Maybe he just throws your papers down the stairs and grades you based on how far your paper has landed.
• There is a lack of precision in trust. No way to simply measure it.

Work Needs to be Done

• Case Study: A Brick.
  • The most secure computer.
  • But does not really do anything.

Non-Goals

• Prevent denial of service. (Not solved by dealing with Access Controls).

Basic Technique - Access Control List

• Take every object, every user, and every circumstance and see which are allowed.
  • Objects can be files, etc.
  • Users are known as principals if acting on their behalf.
  • Users are known as proxy or proxies when they are puppetted, like at gunpoint.
  • Circumstances are access types, such as read, write, etc. (there is quite a few).
• Given the three pieces of information, the OS checks the Access Control List to make sure that the action can be allowed.
• Each piece of information is marked by a bit, and each entry is a particular user-object-circumstance action, and the list is a list of a lot of user-object-circumstance actions.

• In theory it is good.
• But in practice, using Principle Object Access-type (POA) bit system has problems:
  • Inefficient
  • No meta-control (who controls the access control lists?)
  • Maintainability (imagine the size of the access control list with more than 10,000 users, more than 100,000 objects and more than 25 actions, IE UCLA)
  • Bad scaling
  • More complex means more mistakes
    • Unintentional denied access is noted and fixed however
    • Unintentional granted access are left unnoticed
  • Difficult to add new elements (adding a new user requires every Access Control List entry to be altered)

Simplified Access Control - the Unix Model

• Objects are files.
• Principals are UNIX users.
• Accesses are read, write, execute.
• If you type `$ls -l file` into bash, it will display the Access Control Bits in front of the entry:

• Reusing bits:
• The execute bit
  • For a regular file, the execute bit allows the contents of the file to be run as a program.
  • However, in the case of a directory, the execute bit allows a user to search the files contained in the directory.
• The setgid bit
  • For a regular file, when it is executed, the newly created process will run as the group of the file rather than the user's group.
  • For directories, a file created in the directory will belong to that group, rather than your own.
  • This feature exists to facilitate collaboration between users on a machine.
• The sticky bit
  • For regular files: If this file goes into RAM/swap space, try to keep it in memory. This is a deprecated performance optimization.
  • For directories, even if you have write permissions in this directory, you may not remove files created by other users.
  • A classic example in the Unix file system where the sticky bit is set is the /tmp directory.
• The simplified model is much easier to maintain, and can support many file and user changes.
• Problem: This system makes it difficult to share a file with certain users, but not others, without rearranging the system's group structure. Fix: Access Control Lists.

Sidebar: Why is there a rwx for the user? What good is marking a file unreadable for the creator?

Reply: The use of the user bits are voluntary, serve as reminder bits to the user. Likewise, in the traditional ACL POA bit combinations, there are many useless combinations, likewise there are some combinations of the UNIX permissions that are pointless.

Access Control Lists

• Found in Windows NT, Solaris and Samba
• Simlilar to the UNIX access control, but with a list of access rights associated to an object.
• Example: myfile.txt

  Eggert	rwx
  Kuo	r--
  Other	--x

  • Associated with each object is a list of access rights.
  • Elements in the list are principals or groups of people.
  • When a principal attempts to access a file, the OS looks through the ACL for that file to see what permissions the principal has for it.
  • getfacl() gets the file access control list.
  • setfacl() sets the file access control list.
  • In this implementation, maintaining access control rights is in the hands of the users instead of system administrators.

Role-Based Access Control

• Used in Oracle, Solaris, Active Directory, etc.
• A role in real life is a task someone performs like being a grader, reviewer or email reader.
• In computing, a role is what a user is intended to do on a computer, such as a student, teacher or system administrator.
• The concept of roles is intended to keep computer users from making dumb mistakes as well as prevent users from acting outside their given roles.
• In a role-based system, access rights are tied to roles, not principals (users).
• This means that as a principal switches roles, they can actually lose rights.
• This is good because different sessions have different roles.
• The email reader session will not have the same role (and thus, not the same rights) as the grader session.
• Role-based access control is associated with operations, not just objects.
• Traditional UNIX lets users unlink a directory and create garbage as long as they are root.
  • With role-based access control, the user must be root and take on the role of system administrator to be able to do the above operation.
• There is a list that specifies what roles a user is allowed to acquire.
• This prevents unauthorized users from acquiring powerful roles like system administrator.
• In UNIX, if a user belongs to multiple groups, he always has all the power that the combination of groups gives him.
• With role-based access control, even if the user belongs to multiple roles, he can choose which role he wants to be in at any given time, which makes his computer use safer.

Capabilities

• Capabilities are fundamentally different from UNIX and role-based access control.
• Whereas those techniques seek to protect objects by limiting access to them, capabilities do the same by restricting processes.
• By analogy, if the UNIX and role-based access control schemes put a fence around objects, capabilities put a fence around processes instead.
• The idea of capabilities is to keep a record for each process of what objects it can access and what accesses are allowed.
• The process descriptor contains a list of capabilities for the process, analogous to file descriptors in UNIX maintaining the permissions for a file.
• Like more traditional access control schemes, capabilities:
  • Must be unforgable.
  • Must be examined on every access.
  • Require OS support.
  • Are only changeable by the OS.
• You can not remove access to an object with capabilities, as object access is not controlled by capabilites.

Building Capabilities

• Method 1: The OS maintains a table for each process and uses system calls to modify the table.
  • Pros and Cons:
    • Capabilities can not be transferred.
    • Capabilities are not first class.
    • This is a simpler and original approach.

• Method 2: Capabilities are maintained with encryption.
  • Method for implementing capabilities with encryption:
    • Take a look at all the objects in a system.
    • Give each object an ID.
    • Encrypt the list of object IDs.
  • Pros and Cons:
    • Capabilities can be transferred.
    • Encryption is breakable.

Software Security

• How to give away a file descriptor to another user:
  1. Call fork() to clones the file descriptor.
  2. Call execvp("progX", ...) .
     • If setuid is set to joeschmoe, some other user now has access to your file descriptor.
     • This seems like a gaping security hole, but the real problem is whether or not to trust progX , not the ability to transfer file ownership.

• Some programs do need special rights:
  • How login works:
    • Prints "Login:"
    • Needs name password.
    • Checks that the supplied password match.
    • login becomes that name by calling setuid( index_of_name_password).
      • This must be a privileged system call.
    • It runs execvp("/bin/sh", ...) .
  • Su , sudo and sendmail also need to be trusted because they need to become other users in order to satisfy their purpose.
• Which software should we trust and in what context?
  • It is expensive to develop trusted software.
    • Requires experienced developers, audits, internal tests and third party testers.
  • How do you trust software that you got off the net?
    1. Read the source code and verify its integrity.
    2. Run a certificate check against the file.  However, this requires someone at some point to read the code and trust it for this second option to be valid, which is still the same as the above method.
• What is an MD5 check?
  • It is a hash function that verifies the integrity of a file you downloaded.
  • It works as follows: H(bigFile) = h ( h is small checksum).
  • If the file changes by even one bit, the checksum should be different so you know that file has been compromised.
  • The checksum should not give any information about the bigFile (there should be no way to make a function such that H'(h) = bigFile ).
• Reflections on Trusting Trust
  • By: Ken Thompson
  • This paper says the following:
    • Imagine that login.c has a trojan that allows user ken to login as root without a password on any system.
    • This is easily caught by anyone looking at the source code of login.c .
    • So, instead, the source code for gcc is changed so that whenever it compiles login.c , it injects the trojan even if the actual source code is clean.
    • However, this can be fairly easily found as well.
    • So, the compiler used to compile gcc is changed instead, so that even if you compile a fresh copy of clean gcc source code, the binary will inject the code into the new gcc that will inject the trojan into login.c .
    • Essentially, Ken Thompson proved that this sort of malicious action can go all the way up the chain as far as it needs to avoid suspicion.
    • His main argument was that at some point, you will need to trust the people who write your software and if you do not, there is no way to trust the software itself.

The Big Picture: You must have a trusted computing base.  Kind of like bootstrapping, you have to start somewhere and trust some code and some programmers.  From there you can be paranoid with all other code and software, but you have to have a core base of software that you just trust.

Contributors:
Dominique Moreno
Sean Moon
Ryan Evans
Yangmun Choi