Access Control

• This is chapter 2.2 Read it.
• How do we protect objects (files, tables, hardware, ...)?
• We would like a flexible system
  • Different access levels (read, write, remove, modify)
  • For different types of users.
  • Robust
  • Easy to use
  • Efficient.
• Basic Terminology
  • Subjects are users, often accessing via a program.
  • Objects are the things to which we want to control access.
    • Files
    • Fields in a database table.
    • CPU time on a processor
  • Access modes are the levels of control
    • Examples, in no order
      • read, write, modify
      • delete, execute, create
      • destroy, copy, import, export
• Again Access Control limiting who can access what in what ways.
  • In this sense, it is a mechanical process controlling access.
  • A table lookup could work quite nicely.
• An Access Policy is security policy stating how these controls should be implemented.
  • Frequently this is informal and based on need to access.
    • A user is on a project, so they are given full access to all of the project's files.
    • I have access to at least the first level of all student records.
    • Should I be able to look at the grades for a student in Art?
  • This is probably not good or workable in a more secure organization.
  • The book states that access policies should be based on an explicit high level security policy.
• Goals of Access Policies
  • Check every access
    • If authorization is changed, the access should change
    • Immediately, no caching.
    • Think about controlling a break in while it is in progress.
    • I assume this can be very difficult in a centralized control, distributed access system.
  • Enforce least privilege
    • Principle of least privilege "A subject should have access to the smallest number of objects necessary to preform some task."
    • If you don't need it, you shouldn't have it.
    • Again, with student records, I should probably only have access to my students and advisees.
    • This is both to keep me from doing anything wrong, as well as to limit the damage if someone breaks into my account.
  • Verify acceptable usage
    • Make sure someone doesn't do things that shouldn't be done.
    • Think illegal operations, not unauthorized.
• Tracking access is also listed as important.
  • Is someone who once had rights but should no longer accessing an object (did we forget to delete access)
  • Is something too restricted, should more general access be granted?
  • Should we change the access granularity of a project?
• Granularity
  • Are we granting access rights on a system level? (ie access or no access to a computer)
  • On a directory level?
  • On a file level?
  • Databases can go even finer than this, ie a table, or even record level.
  • The finer the granularity, the more policies and enforcement mechanisms must be maintained.
  • But the better security is controlled.
• Logging access
  • On certain systems, it is appropriate to log actions taken.
  • We saw this in /var/log/auth.log and the web log.
  • This is expensive,
    • Time wise, it delays actions.
    • Space wise to save the information
    • And for a more solid logging system, the logs should be stored in another, more secure, machine. Possibly off site.
  • But it allows us to know who is using a resource. And when
  • Useful for system failures.
  • And in cases of object misuse.
  • And even more in the case of security compromise.
• They return to limited privilege
  • This is a balance between CIA (CI vs A) why?
  • It is a management issue, not a technical issue.