Notes for November 28, 2000

1. Greetings and Felicitations!
   1. Discuss project
2. Puzzle of the day
3. Privilege in Languages
   1. Nesting program units
   2. Temporary upgrading of privileges
4. Access Control Lists
   1. UNIX method
   2. ACLs: describe, revocation issue
5. MULTICS ring mechanism
   1. MULTICS rings: used for both data and procedures; rights are REWA
   2. (b₁, b₂) access bracket - can access freely; (b_{3, b4) call bracket - can call segment through gate; so if a's access bracket is (32,35) and its call bracket is (36,39), then assuming permission mode (REWA) allows access, a procedure in:
      rings 0-31: can access a, but ring-crossing fault occurs
      rings 32-35: can access a, no ring-crossing fault
      rings 36-39: can access a, provided a valid gate is used as an entry point
      rings 40-63: cannot access a}
   3. c. If the procedure is accessing a data segment d, no call bracket allowed; given the above, assuming permission mode (REWA) allows access, a procedure in:
      rings 0-32: can access d
      rings 33-35: can access d, but cannot write to it (W or A)
      rings 36-63: cannot access d
6. Capabilities
   1. Capability-based addressing: show picture of accessing object
   2. Show process limiting access by not inheriting all parent's capabilities
   3. Revocation: use of a global descriptor table
7. Lock and Key
   1. Associate with each object a lock; associate with each process that has access to object a key (it's a cross between ACLs and C-Lists)
   2. Example: use crypto (Gifford). X object enciphered with key K. Associate an opener R with X. Then:
      OR-Access: K can be recovered with any D_i in a list of n deciphering transformations, so
      R = (E₁(K), E₂(K), ..., E_n(K)) and any process with access to any of the D_i's can access the file
      AND-Access: need all n deciphering functions to get K: R = E₁(E₂(...E_n(K)...))

Puzzle of the Day

Your UNIX system has been attacked. The uucp entry in your /etc/passwd file has a UID of 0. You have run ps to see if any unusual processes were executing. None were. You ran ls to find any unusual files or directories. None were reported. You ran du to determine if the size of any file system was unusually large (indicating hidden files). Nope.

You suspect that someone has, somehow, hidden files (or directories) and an executing process. You decide to start at the /dev directory, to see if they created any new device files. Again, an ls lists only those files you expect to see. But you are still suspicious, and want to confirm the results.

1. What would you do?
2. You still suspect that the attacker left an illicit process executing. But ps showed nothing. How would you confirm or refute your suspicion?

Matt Bishop Office: 3059 Engineering Unit II Phone: +1 (530) 752-8060 Fax: +1 (530) 752-4767 Email: bishop@cs.ucdavis.edu

Copyright Matt Bishop, 2000. All federal and state copyrights reserved for all original material presented in this course through any medium, including lecture or print.