Implementing Access Control

• Access control is frequently implemented at an os level
  • As such, it is limited by the capabilities of the os
    • Files are implemented as an atomic unit from the pov of the access control system.
    • Finer grain control is delegated to the application such as a database
  • Which, in turn, is limited by the capabilities of the hardware.
    • The OS has a somewhat limited view of network traffic.
    • Finer grain control is probably handled by the application, or even by network appliances.
  • The Reference Monitor is an idealized access control structure
  • It consists of three properties
    • Always invoked (validates every single access)
    • Immune from tampering
    • verifiable.
• They go on to present several models of access control
• Access Control Directory. (P77)
  • Like a file directory.
  • Objects and access rights are listed per user
  • There is an owner for any object
    • They have the right to add or deny other access rights (r,w,x,...) for themselves and other users.
  • Clearly write permission in this system must be controlled so users can not defeat the system.
  • This system suffers when the list of files becomes too large.
    • There must be a list, for each user, of all the files they have access to.
    • Which can become immense.
    • And with many users, permission changes to a single file could require hundreds or thousands of file writes.
    • Unique file names become problematic as well
• Access Control Matrix is a second system (P 79)
  • This is a table where
    • Objects make up the columns
    • Subjects (users) make up the rows.
    • The cells contain the access privileges for each.
  • Since this matrix is sparse, it can be represented as a table
    • Subject-Object and permissions where such exist.
    • No blank where there is no permission.
  • In either case, this is very difficult/expensive to search
• A third method is Access Control Lists (P 81)
  • A master file lists the objects.
  • Each object has a file that lists the subjects and their permissions.
  • This has the following advantages
    • Generic policies can be stored for each object.
      • Thus you don't need an entry per user for generic permission.
  • This is the unix ugo, rwx system. (sort of)
• A somewhat different system is a capability
  • A single or multi-use ticket to access an object or service.
  • The user obtains an unforgeable token from an authorization source.
  • This is used to allow access to some asset (file, drive, process, ...)
  • The OS can hold this ticket and the user provides a "link"
  • Or the ticket is encoded and only the user holds the key to decode.
  • The system may allow users to "pass on rights" or not.
• Let's discuss *nix quickly
  • There are three levels (user, group, other)
    • Your user id is assigned in the password file.
    • Your group is either assigned in the password file or the group file.
      • There are other mechanisms but I have never seen these used.
  • The most restrictive level applies
  • Each file has three sets of three access tokens (plus a few others)
    • read (r), write (w), execute(x).
  • For files
    • r - means you can read the file but not change it.
    • w - means you can write to the file.
    • x - means you can "run" the file as an executable.
  • Fir directories
    • r means you can list the directory.
    • w means you can create new files in this directory
    • x means you can travel through this directory.
  • As we have seen, some files have an s for the execute bit.
    • This means that they are set-userid
    • Like /etc/passwd, this means when the program is run, it is run as the owner, not the user executing it.
    • This is the mechanism that allows normal users to execute things as root.
    • This is a dangerous mechanism and object of many security problems
      • including pwnkit.