Access Control. Authorization I
CS 3IS3
Ryszard Janicki
Department of Computing and Software, McMaster University, Hamilton, Ontario, Canada
Acknowledgments: Material based on Information Security by Mark Stamp (Chapters 8.1-8.5)
Ryszard Janicki
Access Control. Authorization I 1/28
Authentication vs Authorization
Authentication – Are you who you say you are? Restrictions on who (or what) can access system
Authorization – Are you allowed to do that? Restrictions on actions of authenticated users
Authorization is a form of access control But first, we look at system certification. . .
Ryszard Janicki
Access Control. Authorization I 2/28
System/Software Certification
Software Certification: open problem, testing is not enough and formal proofs are not feasible for most of the software. McMaster Software Certification Group is a world leader in this area.
System Certification Guidance: Trusted Computing System Evaluation Criteria (TCSEC), 1983
Goals (rather directions than strict criteria):
Provide way to assess security products
Provide general guidance/philosophy on how to build more
secure products
Four divisions labeled D thru A D is lowest, A is highest
Divisions split into numbered classes
Ryszard Janicki
Access Control. Authorization I 3/28
Divisions
D: minimal protection – losers that can’t get into higher division
C: discretionary protection, i.e., don’t enforce security, just have means to detect breaches (audit)
C1: discretionary security protection
C2: controlled access protection
C2: slightly stronger than C1 (both vague)
B: mandatory protection – B is a huge step up from C C: break security, you might get caught
B: “mandatory”, so you can’t break it
B1: labeled security protection
All data labeled, which restricts what can be done with it This access control cannot be violated
B2: structured protection – adds covert channel protection onto B1 B3: security domains – on top of B2 protection, adds that code must
be tamperproof and “small”
A: verified protection – like B3, but proved using formal methods Such methods still (mostly) impractical or infeasible
Ryszard Janicki
Access Control. Authorization I 4/28
Common Criteria (1998) – Evaluation Assurance Levels (EALs)
EAL1 – functionally tested
EAL2 – structurally tested
EAL3 – methodically tested, checked
EAL4 – methodically tested designed, tested, reviewed EAL5 – semiformally designed, tested
EAL6 – semiformally verified, designed, tested
EAL7 – formally verified design and tested
Note: product with high EAL may not be more secure than one with lower EAL
Similarly, product with an EAL may not be any more secure than one without it
EAL4 is most commonly sought
EAL7 requires formal proofs (not too often, cost and difficulties)
Who performs evaluations? Government accredited institutions.
Ryszard Janicki
Access Control. Authorization I 5/28
Lampson’s Access Control Matrix (UNIX)
Subjects (users) index the rows
Subjects (users) index the rows
Objects (resources) index the columns
Objects (resources) index the columns
x – execute, r – read, w – write
Bob Alice
Sam
Accounting program
OS
Accounting Accounting Insurance Payroll
rx
rx
rwx
rx
program
data data data
rx
rx
rwx
rx
r
r
r
rw
rw
rw
rw
rw
rw
rw
Part 2 Access Control 68
Ryszard Janicki
Access Control. Authorization I 6/28
Lampson’s Access Control Matrix
Access Control Matrix
Access control matrix has all relevant information Could be 100’s of users, 10,000’s of resources
Then matrix has 1,000,000’s of entries How to manage such a large matrix?
Note: We need to check this matrix before access to any resource by any user
How to make this more efficient/practical? Two approaches: Access Control Lists
Capabilities
Ryszard Janicki
Access Control. Authorization I 7/28
Access Control Lists (ACLs)
Access Control Lists (ACLs)
ACL: store access control matrix by column ACL: store access control matrix by column
Example: ACL for insurance data is in blue Example: ACL for insurance data is in blue
OS
Accounting Accounting Insurance Payroll
program
data data data
rx
rx
r
rx
rx
r
rw
rw
rwx
rwx
r
rw
rw
rx
rx
rw
rw
rw
Bob Alice
Sam
Accounting program
Part 2 Access Control 70
Ryszard Janicki
Access Control. Authorization I 8/28
Capabilities (or C-Lists)
Capabilities (or C-Lists)
Store access control matrix by row Store access control matrix by row
Example: Capability for Alice is in red Example: Capability for Alice is in red
OS
Accounting Accounting Insurance Payroll
rx
rx
rwx
rx
program
data data data
Bob
Alice
Sam
Accounting program
rx
rx
rwx
rx
r
r
r
rw
rw
rw
rw
rw
rw
rw
Part 2 Access Control 71
Ryszard Janicki
Access Control. Authorization I 9/28
ACLs vs Capabilities
ACLs vs Capabilities
r
Alice — r
w Bob r
rw
Fred r r
Access Control List
—
file1
file2
Note that arrows point in opposite directions… Note that arrows point in opposite directions. . .
With ACLs, still need to associate users to files
r
Alice w rw
Bob r r
r
Fred — r
—
Capability
file1
file2
file3
file3
With ACLs,still need to associate users to files
Part 2 Access Control 72
Ryszard Janicki
Access Control. Authorization I 10/28
Confused Deputy
used Deputy
ILL
Alice can invoke compiler with a debug filename
Access control matrix
Alice not allowed to write to BILL
o) rite
e
ed to
Two resources: Compiler and BILL file (billing info)
Compiler can write file BILL
Compiler BILL Alice
Compiler
x
rx
rw
73
Ryszard Janicki
Access Control. Authorization I 11/28
f
B
f w
k a
e
ACL’s and Confused Deputy
Compiler BILL Alice
x
–
rx
rw
ACL’s and Confused Deputy
Compiler
Compiler
Compiler is deputy acting on behalf of Alice
Compiler is deputy acting on behalf of Alice Compiler is confused
Compiler is confused – Alice is not allowed to write BILL o Alice is not allowed to write BILL
CompilCeromhapsilecornhfuasecdointfsursigehdtsitwsitrhigAhtliscew’sith Alice’s Part 2 Access Control 74
Alice
BILL
Ryszard Janicki
Access Control. Authorization I 12/28
Confused Deputy II
Compiler acting for Alice is confused
There has been a separation of authority from the purpose for which it is used
With ACLs, more difficult to prevent this
With Capabilities, easier to prevent problem
Must maintain association between authority and intended
purpose
Capabilities – easy to delegate authority
Ryszard Janicki
Access Control. Authorization I 13/28
ACLs vs Capabilities
ACLs
Good when users manage their own files
Protection is data-oriented
Easy to change rights to a resource
Capabilities
Easy to delegate – avoid the confused deputy
Easy to add/delete users More difficult to implement
Ryszard Janicki
Access Control. Authorization I 14/28
Multilevel Security (MLS) Models
Ryszard Janicki
Access Control. Authorization I 15/28
Classifications and Clearances
Classifications apply to objects
Clearances apply to subjects
US Department of Defense (DoD) uses 4 levels:
TOP SECRET SECRET CONFIDENTIAL UNCLASSIFIED
To obtain a SECRET clearance requires a routine background check
A TOP SECRET clearance requires extensive background check
Practical classification problems
Proper classification not always clear Level of granularity to apply classifications Aggregation – flipside of granularity
Ryszard Janicki
Access Control. Authorization I 16/28
Subjects and Objects
Let O be an object, S a subject O has a classification
S has a clearance
Security level denoted L(O) and L(S)
For DoDlevels, we have
TOP SECRET > SECRET > CONFIDENTIAL > UNCLASSIFIED
Ryszard Janicki
Access Control. Authorization I 17/28
Condentiality Policies
Clearances & Classications
Clearances & Classifications
The Bell-LaPadula Model
TOPSECRET (TS) SECRET (S) CONFIDENTIAL (C) UNCLASSIFIED (UC)
John, Bob
Sally, Alain
Mark, Ryan
Jane, Spencer
Personnel Files
E-Mails
Activity Logs
Telephone Directory
The most sensitive at the top and the least sensitive at the
The most sensitive at the top and the least sensitive at the
bottom.
bottom.
Ryszard Janicki Condentiality Policies 5 / 19
Ryszard Janicki
Access Control. Authorization I 18/28
Multilevel Security (MLS) and Applications
MLS needed when subjects/objects at different levels access
same system
MLS is a form of Access Control
Military and government interest in MLS for many decades
Lots of research into MLS
Strengths and weaknesses of MLS well understood Many possible uses of MLS outside military
Classified government/military systems Business example: information restricted to
Senior management only, all management, everyone in company, or general public
Network firewall
Confidential medical info, databases, etc.
Usually, MLS is not really a technical system, more like part of a legal structure
Ryszard Janicki
Access Control. Authorization I 19/28
MLS Security Models
MLS models explain what needs to be done
Models do not tell you how to implement
Models are descriptive, not prescriptive
That is, high-level description, not an algorithm
There are many MLS models
We’ll discuss simplest MLS model
Other models are more realistic Other models also more
complex, more difficult to enforce, harder to verify, etc.
Ryszard Janicki
Access Control. Authorization I 20/28
Bell-LaPadula or BLP (Plain)
BLP security model designed to express essential requirements for MLS
BLP deals with confidentiality
To prevent unauthorized reading
Recall that O is an object, S a subject Object O has a classification
Subject S has a clearance
Security level denoted as L(O) and L(S)
BLP consists of
Simple Security Condition: S can read O if and only if
L(O) ≤ L(S)
*-Property (Star Property): S can write O if and only if
L(S) ≤ L(O)
No read up, no write down. Why?
Ryszard Janicki
Access Control. Authorization I 21/28
Condentiality Policies
Clearances & Classications
Clearances & Classifications
The Bell-LaPadula Model
TOPSECRET (TS) SECRET (S) CONFIDENTIAL (C) UNCLASSIFIED (UC)
John, Bob
Sally, Alain
Mark, Ryan
Jane, Spencer
Personnel Files
E-Mails
Activity Logs
Telephone Directory
The most sensitive at the top and the least sensitive at the
The most sensitive at the top and the least sensitive at the
bottom.
bottom.
Ryszard Janicki Condentiality Policies 5 / 19
Ryszard Janicki
Access Control. Authorization I 22/28
Simple Security Condition & ∗-Property
While the simple security condition is natural one, the condition L(S) ≤ L(O) in the definition of ∗-property requires some explanation.
In example on previous page (page 22), Mark and Ryan cannot read personnel files, but John can read any of the files, assuming that discretionary access controls allow it.
Should John decide to copy the contents of personal files into the activity log files and set the discretionary access permissions appropriately, Mark and Ryan could the read the personnel files.
The condition L(S) ≤ L(O) in the ∗-property prevents it. A subject may write to an object without any reading.
Paul is a private investigator hired by John to check if John’s girlfriend Alice, cheats on him. John has a file on Alice, but Paul cannot look into it. However by submitting a report to John, Paul writes to the file on Alice.
Ryszard Janicki
Access Control. Authorization I 23/28
BLP with Tranquility and Bottom Line
Plain BLP is considered as too simple and primitive BLP enhanced with tranquility property
Strong tranquility: security labels never change
Weak tranquility: security label can only change if it does not violate “established security policy”
Strong tranquility impractical in real world
Often want to enforce “least privilege”
Give users lowest privilege for current work
Then upgrade as needed (and allowed by policy) This is known as the high water mark principle:
Weak tranquility allows for least privilege (high water mark), but the property is vague
Bottom Line: BLP is simple, probably too simple
BLP is one of the few security models that can be used to prove things about systems
BLP has inspired other security models
Most other models try to be more realistic Other security models are more complex Models difficult to analyze, apply in practice
Ryszard Janicki
Access Control. Authorization I 24/28
Biba’s Model
BLP for confidentiality, Biba for integrity Biba is to prevent unauthorized writing
Biba is (in a sense) the dual of BLP Integrity model (motivation)
Suppose you trust the integrity of O but not O
If object O includes O and O then you cannot trust the integrity of O
Integrity level of O is minimum of the integrity of any object in O
Let I(O) denote the integrity of object O and I(S) denote the integrity of subject S
Biba can be stated as:
Write Access Rule: S can write O if and only if I(O) ≤ I(S)
(if S writes O, the integrity of S is that of S)
Biba’s Model: S can read O if and only if I(S) ≤ I(O)
(if S reads O, the integrity of S ≤ that of O) Often, replace Biba’s Model with
Low Water Mark Policy: If S reads O, then I(S) = min(I(S),I(O))
Ryszard Janicki
Access Control. Authorization I 25/28
Bell-LaPadula vs Biba
BLP vs Biba
high
l e v e l
BLP
L(O)
L(O)
L(O)
low Confidentiality
Biba
high
l e v e l
I(O)
I(O)
I(O)
Integrity low
High Water Mark Low Water Mark
Part 2 Access Control
91
Ryszard Janicki
Access Control. Authorization I 26/28
Compartments I
Multilevel Security (MLS) enforces access control up and down (total order)
Simple hierarchy of security labels is generally not flexible enough
Compartments enforces restrictions across (partial order) Suppose TOP SECRET divided into TOP SECRET {CAT}
and TOP SECRET {DOG}
Both are TOP SECRET but information flow restricted across the TOP SECRET level
Why compartments? Why not create a new classification level?
May not want either of
TOP SECRET {CAT} ≥ TOP SECRET {DOG} TOP SECRET {DOG} ≥ TOP SECRET {CAT}
Compartments designed to enforce the need to know principle Regardless of clearance, you only have access to info that you need to know to do your job.
Ryszard Janicki
Access Control. Authorization I 27/28
Compartments IICompartments
Arrroowws isndicnadteic“a≥t”ere“lati”onrsheipla(tpiaortniasl horidper)
TOP SECRET {CAT}
TOP SECRET {DOG}
TOP SECRET {CAT, DOG}
SECRET {CAT}
TOP SECRET SECRET {CAT, DOG}
SECRET
SECRET {DOG}
Not all classifications are comparable, e.g., Not all classifications are comparable, e.g.,
TOPTOSPECSRECERTE{TC{ACTA}Tv}svsSSEECCRET {CAT,,DOG} MLS can be used without compartments (and vice-versa),
Part 2 Access Control 95 but, MLS almost always uses compartments.
Ryszard Janicki
Access Control. Authorization I 28/28