Presentation is loading. Please wait.

Presentation is loading. Please wait.

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.

Similar presentations

Presentation on theme: "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."— Presentation transcript:

1 Access Control CS461/ECE422 Spring 2012

2 Reading Material Chapter 4 through section 4.5 Chapters 25 and 26 – For the access control aspects of Unix and Windows

3 Outline Access Control Matrix Access Control List Capabilities

4 Access Control in Context

5 AAA 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

6 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

7 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

8 9/29/2010Computer Security I8 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

9 9/29/2010Computer Security I9 Definitions 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

10 Access Matrix: File Example File 1File 2File3File4 User AOwn Read Write Own Read Write User BReadOwn Read Write Read User CRead Write ReadOwn Read Write

11 Access Matrix: Broader Example SubjectsFilesProcessesDisks S1S2S3F1F2P1P2D1D2 S1 controlowner control Read*Read owner wakeup seekowner S2 controlWrite*executeownerSeek* S3 controlwritestop

12 Mediation Implementation

13 Rules Governing Access Matrix Change RuleCommand (by S0)AuthorizationOperation R1Transfer α or α* to S,X‘α*’ in A[S0,X]Store α or α* in A[S,X] R2Grant α or α* to S,X‘owner’ in A[S0,X]Store α or α* in A[S,X] R3Delete α from S,X‘control’ in A[S0,S] or ‘owner’ in A[S0,X] Delete α from A[S,X] R4w <- read S,X‘control’ in A[S0,S] or ‘owner’ in A[S0,X] Copy A[S,X] into w R5Create object XNoneAdd column for X to A; store ‘owner’ in A[S0,X] R6Destroy object X‘owner’ in A[S0,X]Delete column X from A R7Create subject SNoneAdd row for S to A; execute create object S; store ‘control’ in A[S,S] R8Destroy subject S‘owner’ in A[S0,S]Delete row for S from A; execute destroy object S

14 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

15 Slice and Dice File example

16 9/29/2010Computer Security I16 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

17 9/29/2010Computer Security I17 Windows ACL

18 9/29/2010Computer Security I18 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

19 9/29/2010Computer Security I19 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?

20 9/29/2010Computer Security I20 ACL Scaling Groups of users Role Base Access Control – Users can take on role at a time Directory inheritance Negative rights

21 9/29/2010Computer Security I21 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?

22 22 Capabilities 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

23 23 Implementation Tags / descriptors Cryptographic tickets Type system

24 24 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

25 25 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

26 26 Differences 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

27 27 Revocation 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

28 28 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)

29 29 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

30 30 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 file2 – file1 and file2 passed as file descriptors

31 31 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

32 32 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

33 33 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

34 34 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

35 35 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

36 36 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

37 37 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() { return } public write () { return ERROR; } } Compiler.compile(ReadOnlyFile(sourceFile))

38 38 Revocation class Caretaker { Object target; public Caretaker(Object o) { = o; } class Revocable { match(verb, args) { call(target, verb, args); } } revoke() { target = null; } } }; Caretaker caretaker(object); Bob.pass(caretaker.Revocable()); … caretaker.revoke();

39 39 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

40 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

Download ppt "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."

Similar presentations

Ads by Google