Lecture 18: Security II - Access Control

by Yusuke Tanaka, Andy Tran and Kevin Delavega

Access Control Goals

Access Control Techniques

• Access Control Lists (ACL)

  Idea: take every user (or principle in general), object, then write down which users use which object.

  Pseudocode:

  for each pricipal (user)

  for each object

  for each way to access the object

  is it OK to access the object?

  Remark: Not practical if using this pricipal-object-access (POA) model

  • Inefficient - require a 3D array to hold the information
  • Poor maintainablity - drive sys admins nuts, and mistakes are very common
    • Denying-access. This can be fixed as need, although it's very hassle
    • Granting-access. This type of mistakes often goes unnoticed, and very dangerous.
  • Must specify ACLs for every newly added object, principal, or access type.

  Workaround in Unix model: given objects are files, principals are Unix users, and accesses are rwx
  * This model is great in small enviroment with 1 or 2 sysadmins, but this does not work so well in large enviroment.

  ACLs of Windows NT, Solaris, Samba: solution to Unix model in large enviroment. Associated with every object is a list of access types. The access types can be used for any type of principals (user, owner, group, other). This model present a more flexible POA, but also much more complicated.

• Role-Based Access Control

  Used in Oracle, Solaris, and Windows (known as Active Directory)

  Roles: can be assumed by user
  

  e.g: sysadmin, student, professor, ...

  The access rights are tied to the roles of each principal, not to the principal. A principal can lose or gain rights by assuming different roles, as each of your sessions can have its own role.

  This technique, besides being used for objects, is also commonly used for operation (e.g: unlink a directory)

• Capabilities

  Idea: for each process, record which objects it can process, and what accesses are allowed. The capability is recorded in the process descriptor.

  Like traditional ACLs: must be unforgeable, must be examined in every access, must have OS support and/or hardware support

  How do we implement capabilities?

  • 1) call fork(); to clone fd
  • 2) execvp("progX,...."); setuid to the target user
  • Now that process has a copy of your file descriptor
  
  
  • - OS maintains table for each syscall that modifies the table
  • - One way encryption

  A real problem is that progX cannot be completely trusted.

  Some programs do need special rights (e.g. su, sudo, sendmail)

  
  

  setuid bits on executables are used when you want the user to have the permissions of the file owner within that process.

  su, if bad, can screw up everyone in the system.

• Which Software to Trust

  - Expensive to develop trusted software

  • Experienced developers
  • They regularly audit and test the system

  - Suppose you acquire the file from the internet

  • Option A: Read the code yourself
  • Option B: Examine a certificate associated with the application

  A is not a good solution. For a more detailed explanation, see the article "Reflections on Trusting Trust".

  For example:

  login.c

  • if(user=="ken")
  • login as root
  • else
  • login as usr

  Another example: if compiling login.c, a line can be added to gcc.c that will generate malicious code.

  At some point, the user must trust some part of the software. Thus, the user must consider what is part of his or her "Trusted Computing Base".