access control n.
Skip this Video
Loading SlideShow in 5 Seconds..
Access Control PowerPoint Presentation
Download Presentation
Access Control

Loading in 2 Seconds...

play fullscreen
1 / 40

Access Control - PowerPoint PPT Presentation

  • Uploaded on

Access Control. CS461/ECE422 Spring 2012. Reading Material. Chapter 4 through section 4.5 Chapters 25 and 26 For the access control aspects of Unix and Windows. Outline. Access Control Matrix Access Control List Capabilities. Access Control in Context. AAA.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Access Control' - eshe

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
access control

Access Control


Spring 2012

reading material
Reading Material
  • Chapter 4 through section 4.5
  • Chapters 25 and 26
    • For the access control aspects of Unix and Windows
  • Access Control Matrix
  • Access Control List
  • Capabilities
  • Access control part of a broader context
  • Authentication
    • Discussed last time. Bind external entity to system entity
  • Authorization
    • Grant a right or permission to the system entity to access a system resource
  • Audit
    • Independent review of system actions
types of access control policies
Types of Access Control Policies
  • Discretionary Access Control (DAC)
    • Decision made based on identity of requestor and access rules
    • Regular users can adjust the policy
  • Mandatory Access Control (MAC)
    • Decision made by testing labels associated with processes and resources against system policy rules
    • Regular user cannot adjust the policy
  • Role Based Access Control (RBAC)
    • Access decisions defined against roles rather than individual requestors
access control elements
Access Control Elements
  • Subject – system entity capable of access objects. Generally a process in an OS context
  • Object – a resource in a system
    • Often a file
    • Could also be other named resources like mutex, process, network interface, network port
  • Access right – a way that a subject may access an object in the system
    • Read, Write, Execute, Delete, Create, Search, Change Access, Own
access control matrix
Access Control Matrix
  • Access Matrix or Access Control Matrix (ACM) and related concepts provides very basic abstraction
    • Map different systems to a common form for comparison
    • Enables standard proof techniques
    • Not directly used in implementation

Computer Security I

  • Protection state of system
    • Describes current settings, values of system relevant to protection
  • Access control matrix
    • Describes protection state precisely
    • Matrix describing rights of subjects
    • State transitions change elements of matrix

Computer Security I

actually implementing access matrix
Actually Implementing Access Matrix
  • Slice by column
    • Access control list
    • Used by Multics and most modern OS
  • Slice by row
    • Capability list
    • Many implementations in the ‘80’s
    • Often associated with object-oriented systems
unix access control
Unix Access Control
  • Three permission octets associated with each file and directory
    • Owner, group, and other
    • Read, write, execute
  • For each file/directory
    • Can specify RWX permissions for one owner, one group, and one other

Computer Security I

windows acl
Windows ACL

Computer Security I

windows acl1
Windows ACL
  • Actually two ACL's per file
    • System ACL (SACL) – controls auditing and now integrity controls
    • Discretionary ACL (DACL) – controls object access
  • Windows ACLs apply to all named objects
    • Files
    • Pipes
    • Events

Computer Security I

acl distinctions
ACL Distinctions
  • What subjects can modify an object's ACL?
  • If there is a privileged user, do the ACLs apply to that user?
  • Does the ACL support groups or wildcards?
  • How are contradictory access control permissions handled?
  • If a default permission is allowed, do the ACL permissions modify it, or is the default only used when the subject is not mentioned in the ACL?

Computer Security I

acl scaling
ACL Scaling
  • Groups of users
  • Role Base Access Control
    • Users can take on role at a time
  • Directory inheritance
  • Negative rights

Computer Security I

revoking rights with acls
Revoking rights with ACLs
  • Revoking rights for subject s to a particular object o straightforward
    • Remove s from ACL(o)
    • Make sure s has a negative entry in the ACL(o)
  • Example: Alice removes all of Bob's rights to file f
    • What if Bob had given Carol read rights to f?
    • Should Carol still have those rights?

Computer Security I

  • Where are access rights stored
    • ACL: Each resource (file) has an access list
    • Capabilities: Each process has a capability list (C-list)
  • Note: In capabilities, subjects are processes
    • In ACLs, subjects are users (why?)
  • Capabilities act as a ticket
    • Possession of capability implies access rights
  • Tickets must be unforgeable
    • Otherwise access control fails
  • Tags / descriptors
  • Cryptographic tickets
  • Type system
tags descriptors
Tags / descriptors
  • Each process has a list of tickets
    • Tickets stored in a protected segment
    • Programs refer to tickets by pointers / indices
    • Operating system can add / remove tickets
  • E.g. CAP system
  • E.g. UNIX file descriptors
    • UNIX access control a hybrid system: use ACLs to open a file and get a file descriptor, then use fd as a capability
    • More efficient since only have to check permissions on open
cryptographic tickets
Cryptographic tickets
  • Cryptography
    • Associate with each capability a cryptographic checksum enciphered using a key known to OS
    • When process presents capability, OS validates checksum
    • Example: Amoeba, a distributed capability-based system
      • Capability is (name, creating_server, rights, check_field) and is given to owner of object
      • check_field is 48-bit random number; also stored in table corresponding to creating_server
      • To validate, system compares check_field of capability with that stored in creating_server table
      • Vulnerable if capability disclosed to another process
  • Descriptors - managed by the operating system
  • Crypto tickets - managed by the process
  • Copying
    • Descriptors - possible (e.g. UNIX fd passing), but regulated by the OS
    • Tickets - arbitrary copying possible
  • Scan all C-lists, remove relevant capabilities
    • Tags / descriptors - too expensive
    • Crypto tickets - impossible
  • Use indirection
    • Each object has entry in a global object table
    • Names in capabilities name the entry, not the object
      • To revoke, zap the entry in the table
    • Example: Amoeba: owner requests server change random number in server table
      • All capabilities for that object now invalid
    • Can have multiple entries for a single object to allow control of different sets of rights and/or groups of users for each object
acls capabilities and polp
ACLs, Capabilities, and POLP
  • Principle of least privilege
    • “subject should be given only those privileges that it needs in order to complete the task”
    • Granularity of subjects controls how small “least” is
  • Capabilities better enforce least privilege
    • Subjects are processes, not users, can be more restrictive
    • ACLs with roles form a middle ground (next lecture)
least privilege example
Least privilege example
  • Carol wants to use gcc to compile her file
    • gcc may (does) have bugs in it
  • ACLs: gcc runs with Carol’s authority
    • Can overwrite any of Carol’s files
  • Roles: Carol can have separate roles
    • Mail role, development role, browsing role
    • gcc in development role cannot overwrite other files
  • Capabilities
    • Carol gives gcc capabilities to read (particular) source files, write (particular) object files
    • All other files are safe
cp example
cp example
  • Consider unix command ‘cp’
    • cp file1 file2
  • What’s the least authority that cp needs to run?
    • Read and write any file the user owns
  • What about `cat’?
    • cat < file1 > file2
    • file1 and file2 passed as file descriptors
confused deputy problem
Confused Deputy Problem
  • Compilation costs money
    • Compiler writes accounting information to a file called “BILL”
    • Compiler given permission to write to “BILL”
      • Using roles, setuid, …
  • Compiler takes an optional argument with a file where to write debugging output
    • “gcc -d debugfile foo.c”
  • User runs: “gcc -d BILL foo.c”
    • Destroys billing information
what went wrong
What went wrong?
  • Compiler given authority to write to BILL
    • Used it for the wrong purpose
  • How to solve?
    • In UNIX, access() system call checks permission of caller
    • Awkward, error-prone
  • Real problem: ambient authority
ambient authority
Ambient Authority
  • Permission checks not controlled by user / program
    • Authority exercised automatically
    • Doors that magically recognize users, instead of using keys
  • ACLs have ambient authority
  • Capability systems can have ambient authority, most don’t
    • POSIX Capabilities an exception
non ambient authority
Non-ambient authority
  • User / program chooses which authority to use
  • E.g. billing capability
    • open(“BILL”, bill_cap)
    • open(debug_file, debug_cap)
      • Will fail if debug_file == “BILL”
  • Better yet, combine designation and authority
object capability systems
Object Capability Systems

class Compiler {

static private File billFile;

public void compile(File debugFile) {

billFile.append(billing entry);

debugFile.write(debug info);



  • Permissions enforced by type system
    • No way to write to a file without a reference
object capability systems1
Object Capability Systems
  • Object references are capabilities
    • Requires memory safety (why?)
    • Both names the object and grants access
  • Objects are accessed through methods
    • Methods mediate access
  • Execution model and access model unified
  • Objects are subjects as well
    • Low granularity subjects
    • Dynamic subject creation
object proxies
Object Proxies
  • Most policies enforced by proxy object
  • E.g. read-only file access

class ReadOnlyFile {

private File myFile;

public ReadOnlyFile(File f) {

myFile = f;


public read() {



public write () { return ERROR; }


  • Compiler.compile(ReadOnlyFile(sourceFile))

class Caretaker {

Object target;

public Caretaker(Object o) { = o; }

class Revocable {

match(verb, args) { call(target, verb, args); }


revoke() { target = null; }



Caretaker caretaker(object);



acls and capabilities
ACLs and Capabilities
  • ACLs: Answer to “who can access this file”
    • Useful when formulating policies
  • C-List: Answer to “what files can this process access”
    • Useful in investigation
  • Object capabilities don’t answer either question, but integrate authorization decisions in the design
key points
Key Points
  • Access control part of broader system
  • Access Control Matrix or Access Matrix
    • Means to model access control systems
  • Real implementations
    • Access control lists
    • Capability lists
    • Object capabilities