Date post: | 27-Mar-2015 |
Category: |
Documents |
Upload: | nicholas-schultz |
View: | 218 times |
Download: | 1 times |
Secure System Design and Access Control
Nick FeamsterCS 6262
Spring 2009
2
What is Access Control?
• The process by which a computer system controls the interaction between users and system resources
• To implement a security policy, which may be determined by – organisational requirements– statutory requirements (medical records, for example)
• Policy requirements may include– confidentiality (restrictions on read access)– integrity (restrictions on write access)– availability
3
A Schematic View
• A user requests access (read, write, print, etc.) to a resource in the computer system
• The reference monitor– Establishes the validity of the request– Returns a decision either granting or denying access
to the user
Access Request
System Decision
Reference Monitor
4
Reference Monitor
5
Simple Analogies
• Consider a paper-based office in which certain documents should only be read by certain individuals
• We could implement security by – storing documents in filing cabinets – issuing keys to the relevant individuals for the
appropriate cabinets
6
Simple Analogy: Files
• The reference monitor is the set of (locked) filing cabinets
• An access request (an attempt to open a filing cabinet) is granted if the key fits the lock (and denied otherwise)
7
Simple Analogy: Guest List
• The reference monitor is the security guard + the guest list
• An access request is granted only if – a club-goer can prove their identity
(authentication) – she is on the guest list
8
Subjects and Objects
• Subject– Active entity in a computer system
• User, process, thread– We will assume that a subject is synonymous with
a user
• Object– Passive entity or resource in a computer system
• Files, directories, printers
9
Principals
• Principal and subject are both used to refer to the active entity in an access operation
• A principal is generally assumed to be an attribute or property associated with a subject– User ID– Public key– Process– Thread
• A subject may be represented by more than one principal
10
Access Operations
• An interaction between an object and a subject
• A subject may observe (read) an object– Information flows from object to subject
• A subject may alter (write to) an object– Information flows from subject to object
11
Access Control• given system has identified a user • determine what resources they can access• general model is that of access matrix with
– subject - active entity (user, process) – object - passive entity (file or resource) – access right – way object can be accessed
• can decompose by– columns as access control lists– rows as capability tickets
12
Acces Control Matrix
• Introduced by Lampson (1972) and extended by Harrison, Ruzzo and Ullman (1976-8)– Columns indexed by objects– Rows indexed by subjects– Matrix entries are (sets of) access operations– Foundation of many theoretical security models
trash a.out allfiles.txt
jason {r,w} {r,w,x} {r,w}
mick {r,x} {r}
ObjectsSubjects
13
Access Control Matrix
• A request can be regarded as a triple (s,o,a)– s is a subject– o is an object– a is an access operation
• A request is granted (by the reference monitor) if– a belongs to the access matrix entry
corresponding to subject s and object o
14
Access Control Matrix
• The request (jason, allfiles.txt, w) is granted• The request (mick, allfiles.txt, w) is denied
trash a.out allfiles.txt
jason {r,w} {r,w,x} {r,w}
mick {r,x} {r}
ObjectsSubjects
15
Disadvantages
• Abstract formulation of access control
• Not suitable for direct implementation– The matrix is likely to be extremely sparse and
therefore implementation is inefficient– Management of the matrix is likely to be extremely
difficult if there are 0000s of files and 00s of users (resulting in 000000s of matrix entries)
16
Access control lists
• An ACL corresponds to a column in the access control matrix• [a.out: (jason, {r,w,x}), (mick, {r,x})]• How would a reference monitor that uses ACLs check the validity of
the request (jason, a.out, r)?
trash a.out allfiles.txt
jason {r,w} {r,w,x} {r,w}
mick {r,x} {r}
ObjectsSubjects
17
Access Control Lists
• Access control lists focus on the objects– Typically implemented at operating system level– Windows NT uses ACLs
• Disadvantage– How can we check the access rights of a particular
subject efficiently (“before-the-act per-subject review”)?
18
Capability lists
• A capability list corresponds to a row in the access control matrix• [jason: (trash, {r,w}), (a.out, {r,w,x}), (allfiles.txt, {r,w})]• How would such a reference monitor check the validity of the
request (jason, a.out, r)?
trash a.out allfiles.txt
jason {r,w} {r,w,x} {r,w}
mick {r,x} {r}
ObjectsSubjects
19
Capability lists
• Capability lists focus on the subjects– Typically implemented in services and application
software– Database applications often use capability lists to
implement fine-grained access to tables and queries– Renewed interest in capability-based access control
for distributed systems
• Disdavantage– How can we check which subjects can access a given
object (“before-the-act per-object review”)?
20
Analogies Again
• An ACL is analogous to a guest list – the club is the object– the favoured clubbers appear on the list
• A capability list is analogous to the set of keys issued to a user (the subject) for unlocking the filing cabinets (the objects)
21
Trusted Computer Systems
• information security is increasingly important • have varying degrees of sensitivity of information
– cf military info classifications: confidential, secret etc
• subjects (people or programs) have varying rights of access to objects (information)
• known as multilevel security– subjects have maximum & current security level – objects have a fixed security level classification
• want to consider ways of increasing confidence in systems to enforce these rights
22
Control of Information in Computer Systems: Overview
• Focus of paper on multiple user computer system
• User authority– Who can do something to something– Who can see something
• “Privacy” social• Concern here is controlling access to data
(security)
23
Security Violations
• Unauthorized release of information• Unauthorized modification of information• Unauthorized denial of use of information
24
Definitions
• Protection – control access to information• Authentication – verify identity of user
25
Categories of Protection Schemes
• Unprotected– Typical batch system– Physical isolation (computer room)
• All or Nothing– User totally isolated in the system– No sharing of resources– Typical of early TS systems (Dartmouth BASIC)
26
Categories of Protection Schemes
• Controlled Sharing– OS puts limits on access– TOPS-10 file system w/ WRX control
• User-programmed Sharing Controls– Like OO files w/ access methods– User control access as he likes
27
Categories of Protection Schemes
• Putting strings on information– Trace or control information after released– File retains access even when others have it
• Overriding question: How controls can change over time– How is privilege changed?– Can access privilege be modified or revoked on
the fly?
28
Design Principles
• Since we can’t build software without flaws, we need ways to reduce number and severity of security flaws
• What follows are 10 Design Principles to apply when designing and creating protection mechanisms
• They were true in 1975 and remain relevant today
29
Design Principles
• 1. Economy of Mechanism– KISS Principle– Easier to implement– Allows total inspection of security mechanism
30
Design Principles
• 2. Fail-safe Defaults– Default case should be to exclude access
• Explicitly give right to access
– The reverse is risky• i.e. find reasons to exclude• You may not think of all reasons to
exclude
31
Design Principles
• 2. Fail-safe Defaults (cont.)– Easier to find and fix error that excludes
legitimate user• He will complain
– Won’t normally see error that includes illegitimate user
• He probably won’t complain
32
Design Principles
• 3. Complete Mediation– Check every access to objects for rights– All parts of the system must check– Don’t just open the door once and allow all
access after that• Authority may change• Access levels in security mechanism
may change over time
33
Design Principles
• 4. Open Design– Don’t try security by obfuscation or
ignorance• Not realistic that mechanism won’t be
discovered– Mechanism should be public– Use more easily protected keys or
passwords– Can be reviewed and evaluated without
compromising the system
34
Design Principles
• 5. Separation of Privilege– 2 keys are better than one– No one error or attack can cause security
violation– Similar to nuclear weapons authority
process– Not always convenient for user
35
Design Principles
• 6. Least Privilege– Programs and users should run with least
feasible privilege– Limits damage from error or attack– Minimize potential interaction among
privileged programs• Minimize unexpected use of privilege
36
Design Principles
• 6. Least Privilege (cont.)– Designing this way helps identify where
privilege transitions are• Identifies where firewalls should go
– Analogous to the “Need to Know” principle
37
Design Principles
• 7. Least Common Mechanism– Minimize mechanisms shared by all users
(e.g. shared variables)– Shared data can be compromised by one
user– If always shared, all users need to be
satisfied– Example – shared function should be run
in users space rather than as system procedure
38
Design Principles
• 8. Psychological Acceptability– Design for ease of use
• Then it will be used and not avoided or compromised for user’s convenience
– Model the mechanism so the user can easily understand
• Then will use as intended
39
Design Principles
• 9. Work Factor– Make it cost more to compromise security
than it is worth– Automation can make this principle difficult
to follow– Work factor may be difficult to calculate– Perhaps Public Key Encryption falls into
this category
40
Design Principles
• 10. Compromise Recording– Note all security breaches (and then
change plan?)• E.g. note each file access time
– Not very practical, since can’t tell what data has been taken or modified
41
Summary
• No security system is perfect – at best we minimize the vulnerabilities
• Technology may advance but engineering design principles which were good in 1975 remain relevant today