Comp 527: Homework 2: Systems Security

up to main page

Due date: Tuesday, April 11, 2:30pm

As in homework 1, you should submit your own work, but you're still allowed to study with your peers. Please cite your sources.

Question 1: Access Controls

In class, we talked about the plethora of grouping mechanisms used to make access controls easier to specify. Unix and NT have groups. Other systems have roles.

Consider a system being designed to support homework management for a class like Comp314 with group projects (where the groups change from assignment to assignment), written assignments (done individually), labbies, teaching assistants, and a professor or two. Write down the operations that you expect would be required of the grade management system and write an appropriate security policy for deciding who is allowed to read and write which entries in the database. Your security policy should be stated in formal terms based on the bits in the access control matrix.

Your security policy should specify operations for reading and writing to the grading database. It should also specify operations for adding and removing students, labbies, assignments, and all that.

Question 2: Network Security & DNS

Consider how Akamai works. You get to offload your <img> references to Akamai servers which are distributed around the globe. When a customer visits your Web site, the images are loaded from a server closer to the client than your server, thanks to some no-doubt patent-pending algorithms designed by those Akamai wizards.

Akamai actually does this by playing fancy games with the domain name system (DNS maps a name like www.yehoodi.com to an IP address like 209.15.16.240). To see this in action, go to cbs.sportsline.com and check out the HTML. You'll see references to URLs that begin with http://a380.g.akamaitech.net/.

Imagine Akamai has just gotten going as a brand new startup, and you were hired to think of all the security attacks they might have to thwart. Given everything you learned in class, come up with an action plan for the fledgling Akamai.

  1. How should they secure their (physically distributed) servers?
  2. How should they allow their customers to upload new data?
  3. How can they make sure DNS will point local users to local servers?
  4. What kinds of network-based attacks could cripple their service and what should they do to alleviate the threat?
  5. Akamai charges its clients based on the number of hits they receive. Higher volumes cost more money. Where can this system be abused and how might Akamai be able to accurately and provably account for the number of hits it's receiving?

Question 3: Type Checking vs. Page Tables

Java has four different kinds of protection labels on object fields and methods: private, protected, public, and a default label sometimes called package-scope. A private variable may only be accessed by code running in the same class. A package-scoped variable may be accessed by code running in any class inside the same package (i.e., java.lang). Public variables may be accessed by anybody. Protected variables are somewhat funny, being accessible either by any subclass or by any class within the same package. For the purposes of this question, you may ignore the protected label and focus on the other three. Likewise, you may ignore static members and functions.

The other rule is that in order to access a member of a class instance (i.e., something allocated by using the new operation), you must already have a reference to the instance. In this respect, a class instance reference act as capability to access the class.

As we've seen, a sufficiently crafty adversary might be able to find a bug in the type checker and use this to override the above rules. One proposed solution is to use the hardware page tables instead of a type checker to enforce program safety. Describe exactly how you might safely support the following Java primitive operations:

new
allocate an object of some type, returning a reference
invoke
call a method on some class, passing arguments and returning a value
getfield
read a variable from a class instance
putfield
write a variable to a class instance
Would you trap every memory access in the kernel? Could you represent an object reference as a direct memory address or would you need a descriptor table of some kind? Could you optimize the cases for public and package-scoped variables by keeping more pages mapped for read/write? How much trusted code must run in kernel mode vs. user mode? If you could rearrange how objects are located in memory, could you use this as an optimization?

You may assume your kernel supports an operation like Solaris mprotect(2) and kernel trap handlers can emulate the behavior the trapped instruction should have caused and then resume execution in the user code.

Dan Wallach, CS Department, Rice University
Last modified: Tue Mar 28 23:03:05 CST 2000