access control models and policies · mandatory access control (mac) access rights are based on...
TRANSCRIPT
Tuomas Aura T-110.4206 Information security technology
Access control models and policies
Aalto University, autumn 2011
Outline
1. Access control
2. Discretionary AC
3. Mandatory AC
4. Other AC models
2
ACCESS CONTROL
3
Access control (AC)
Subjects request actions on objects
– Alice wants to read a file
– Bob wants to update account balance
– Process wants to open a socket
AC = authentication + authorization
– authentication = verifying the identity of the subject
– authorization = checking that the subject has the right to perform the requested action on the subject
4
Reference monitor
Reference monitor controls access by subjects to objects – Grants or denies access requests – Logs events to audit trail – Follows rules set by administrators (i.e. implements a policy)
Trusted computing base (TCB) = all system components that need to be trusted to implement access control – Security kernel = implementation of reference monitor in an OS
But more about the implementation later; now we are talking about policies
5
Objects Subjects Reference monitor
Audit trail
Access rules
Access requests
Access control matrix Access control matrix is the simplest, most
general AC model M : Subjects × Objects → Actions
AC matrix represents the protection state of a
system
6
Alice Bob Process 4567
Process 6789
file1.txt read, write read read, write append
file2.txt write read - -
Socket s - - - open, read, write, close
Protection systems AC matrix represents the static protection state Dynamic protection systems are more interesting Subjects and AC matrix cells can also be objects
– Access to them is also controlled by the matrix
Protection state transitions – Subjects may grant and remove access rights – Subjects may create and destroy subjects and objects
Early research on computer security studied protection systems with different definitions of state transitions – Safety question: given an initial state and implementation of
transitions, can subject s get the access right r to object o? – E.g. HRU model (safety undecidable), take-grant model (safety
decidable)
Study of protection systems is not so relevant today, but AC matrix is still a useful way to think about access control
7
Background information if you want to read classic computer security literature
DISCRETIONARY ACCESS CONTROL
8
Discretionary access control (DAC) Data owners, usually users, set access rights Subjects are trusted to make decisions about sharing access rights
with others – Users decide who is allowed to access their files – User who can read a secret file can also print and email it – Process that can read a secret file can also send it to the network
DAC is also called identity-based AC Typical in commercial and consumer systems There may be a policy against sharing and access may be audited,
but the policy is not enforced technically Examples of DAC outside computers:
– Person with a key can open the door to others; door keys can be shared and copied
– Tell your friend a secret on the condition that he does not tell it to anyone else
9
Access control list (ACL) ACL = list of the access rights associated with an
object ACLs are another way to represent the AC matrix:
one row of the matrix is stored with each object – file1.txt ACL:
Alice: { read, write }; Bob: { read }; Process 4567: { read, write }; Process 6789: { append }.
– file2.txt ACL: Alice: { write }; Bob: { read }.
– Socket s ACL: Process 6789: { open, read, write, close }.
ACL examples: – Key cards, table reservations, Windows file system
10
Capabilities Capability = an access right associated with the subject
Capabilities are another way to represent the AC matrix: one column is stored with each subject – Alice’s capabilities:
file1.txt: { read, write }; file2.txt: { write }.
– Bob’s capabilities: file1.txt: { read }; file2.txt: { read }.
– Process 4567 capabilities: file1.txt: { read, write }.
– Process 6789 capabilities: file1.txt: { append }; Socket s: {open, read, write, close }.
Examples of capabilities: – metal keys, driver’s license, parking permit
11
MANDATORY ACCESS CONTROL
12
Mandatory access control (MAC) Access rights are based on rules (i.e. policy) set by
administration The AC policy is enforced and cannot be changed by users Subjects cannot leak access rights to others
– User can read a secret file but cannot copy, print or email; file viewer application prevents cut-and-paste and screen shots
– One process can access the Internet, another write files to the disk
MAC is also called rule-based AC MAC originates from military policies
– Intelligence officer may not be allowed to read his own reports – Officer can read a secret plan but cannot take a copy out of the
room – Officer who has contact with foreign agents may lose access to
classified information
13
Mandatory access control (MAC) MAC has some uses in commercial systems
– DRM: Alice can play the music she has purchased, but cannot share it
– Malware isolation: Host firewall may block potential spyware from making outbound connections to prevent information leaks
Examples of MAC-like systems outside computers: – Biometric authentication cannot be shared, e.g. photo on
driver’s license or signature on credit card
– Admit-one event tickets: UV stamps, shredding bracelets
– In UK, jurors must not read newspapers or watch TV about the case so that they are not influenced by them
14
Clearance and classification
Mandatory access control rules are often based on security labels on subjects and objects – Subject clearance
– Object classification
l : (Subjects ∪ Objects)→Labels
MAC based on clearance and classification levels is also called multi-level security (MLS)
Simple security property: S can read O iff l(S) ≥ l(O)
15
Top secret
Secret
Confidential
Unclassified
High
Low
Multi-level security Labels depend on the organization but should
form a lattice ⟨ Labels, ≥ ⟩ (i.e. a partial order with join ∨ and meet ∧ operations)
Example. military security labels Levels: top secret > secret > confidential > unclassified Categories = { army, navy, air force } Labels = Levels × P(Categories) Domination relation:
<level1,categories1> ≥ <level2,categories2> iff level1 ≥ level2 and categories1 ⊇ categories2
Theoretical publications often consider only two labels: high > low
How to define labels for commercial systems? 16
17
Top secret, army & navy
Top secret, army Top secret, navy
Top secret, —
Secret, army & navy
Secret, army Secret, navy
Secret, —
Classified, army & navy
Classified, army Classified, navy
Classified, —
Unclassified
Lattice example
⊤
⊥
Labels — Finnish government Asetus viranomaisten toiminnan julkisuudesta ja hyvästä
tiedonhallintatavasta 12.11.1999/1030 http://www.finlex.fi/fi/laki/ajantasa/1999/19991030
Not a lattice, though
18
Bell-LaPadula model
Bell-LaPadula (BLP) is a MAC policy for protecting secrets
– Military security model for computers; military is mostly concerned with protecting secrets
– Observation: the simple security property is not sufficient to prevent secrets from leaking
Bell-LaPadula:
– Simple security property: S can read O iff l(S) ≥ l(O)
– *-property: S can write O iff l(O) ≥ l(S)
Also called: no read up, no write down
19
Biba model
In computer systems, integrity of data and the system is often more important than confidentiality – Which is more important in a bank IT systems?
Biba is a MAC policy for protecting integrity of data
Biba is the dual of Bell-LaPadula: – S can write O iff l(S) ≥ l(O)
– S can read O iff l(O) ≥ l(S)
Also called: no write up, no read down
20
Biba examples
Integrity policies in commercial computer systems: – Web application open in the browser should not write to
the file system
– Type safety should prevent communication between Java or .Net applications running in the same runtime environment
– Virtual machines running in the same host are isolated from each other
21
Information flow security BLP and Biba are information flow policies
– BLP prevents flow of information from high to low – Biba prevents flow if information from low to high
Information flow policies are the basis for many security proofs. Typical proofs show non-interference: – view of one subject is not affected by the data of the other – low output does not depend on high input, or
high output does not depend on low input
How to use BLP and Biba in the same system?
22
System
high input
high output
low input
low output
High water mark, low water mark
What happens to classification when you combine low and high information into a new object?
High water mark policy for secrecy: always set the classification to the highest input
Low water mark policy for integrity: always set the classification if to the lowest input
Problem: – Over time, all documents will become top secret
with the lowest integrity level
23
Upgrading and downgrading Upgrading, downgrading:
– In practice, security levels need to be changed by humans – E.g. downgrading documents for publication – E.g. upgrading intelligence reports that aggregate a lot of low-
level data
Documents may need to be sanitized (i.e. redacted) before downgrading – E.g. removing personal names from military documents before
publication
Sanitization may be difficult – High subjects can use covert channels to leak data intentionally,
e.g. hide data in photos – Mistakes easy to make e.g. US military painting black box over text in PDF e.g. AOL publishing anonymized web search data
24
OTHER ACCESS CONTROL MODELS
25
Clark-Wilson model Data integrity cannot always be expressed in terms of MLS,
i.e. who has access to what data – E.g. transfers between bank accounts must not change the total
balance
Integrity in many commercial systems depends on following the correct procedures
Clark-Wilson model defines rules for commercial systems for how to maintain data integrity: – Transactions must transform data items from a consistent state
to another consistent state – Auditing and procedural controls to enforce this (The specific rules could be different in each system)
Clark-Wilson model has not really been implemented; it is important because of the idea of using accounting rules as a model for security policy
26
Chinese Wall model Conflicts of interest are common in business:
– Consulting company, investment bank, or law office may be advising competing clients and must keep their information separate
– The clients are assigned to different employees who do not exchange information between them
To avoid conflicts of interest, the access control policy must take into account the information previously accessed by the subject
Chinese Wall model: – If subject S has previously accessed an object O1 and the
objects O1 and O2 are in a conflict of interest, then S may not access O2
– Subject can fall to either side of the wall but cannot change sides later
27
Separation of duty Chinese Wall is an example of separation of duty Other separation of duty policies:
– Expense claim requires two signatures: the claimant and an authorized approver, e.g. department manager, but nobody is allowed to approve their own expenses
– Auditors are often required to be from outside the company
– Keys to a safe may be given to two different persons – Lecturers issue grades to students but only study
office staff can enter them into the study register
Unlike BLP and Biba, separation of duty policies are stateful
28
Groups and roles Adding structure to policies Group = set of subjects
– E.g. Administrators, T-110.4206-students – Object ACL can list groups in addition to individual users – Both group membership and ACLs change over time
Role = set of permissions (i.e. permitted actions on objects) – E.g. Administrator, T-110.4206-teacher, SCI-professor – Roles are usually relatively static; their assignment to users
changes
Both are forms of indirection
29
Objects x Actions
Subjects Roles or groups
* * * *
Role-based access control (RBAC) NIST standard Modeling high-level roles in an organization
– E.g. Doctor, Nurse, Student, Lecturer, Course-assistant – Roles defined once; changed infrequently
Roles may be parameterized – E.g. Treating doctor of Mr. Smith, Lecturer or Student
of T-110.4206
Roles may form a hierarchy with inheritance Roles are assigned to users for longer term but
activated on demand for each session Constraints on role assignment and activation can
implement separation of duty
30
Other access control models
Originator-controlled AC (ORCON) – Creator of data retains control over access to it
Attribute-based AC – Access control is based in subject attributes instead of
subject identity
– AC = attribute verification + authorization
– E.g. need to be 18 to buy tobacco; need to be an Aalto student to access course material
– Enables anonymous access
Double-blinded review for scientific journals
Many other AC models have been proposed
31
Why study these AC models?
Abstract models help to see the similarities between different products and implementations – E.g. how many different user interfaces have you seen
that implement an ACL?
They also help to understand the expressiveness and limitations of the technologies – E.g. a stateless AC system cannot implement
separation of duty, while one separation-of-duty policy can often be used to implement others
Some models presented in this lecture are unrealistic! Nevertheless, they can be useful as tools for thinking about security policies
32
Reading material Dieter Gollmann: Computer Security, 2nd ed., chapters 4, 8, 9 Matt Bishop: Introduction to computer security, chapters 2-7 Edward Amoroso: Fundamentals of Computer Security Technology,
chapters 6-13 Ross Anderson: Security Engineering, 2nd ed., chapter 8
Online sources:
– Trusted Computer System Evaluation Criteria. United States Department of Defense. December 1985. DoD Standard 5200.28-STD. (This is the classic “Orange Book”. Just take a quick look.)
– Richard Smith, MLS Introduction, from Handbook of Information Security, Wiley 2006
– Ravi Sandhu, Role-based access control models, IEEE Computer, Feb 1996 (text also here)
33
Exercises What are the subjects, object and actions in Noppa? What security labels and MAC policy would be suitable for
Noppa? Give examples of systems that require confidentiality or
integrity but not both. Which AC model and what kind of security labels could be
used to describe VM isolation? What label would be hypervisor or VM monitor get?
Could you define different confidentiality labels and integrity labels and then use both Bell-LaPadula and Biba policies in the same system? Give an example.
Define RBAC roles that could be used in the implementations of Noppa.
To what extent can your RBAC policy (above) be implemented with groups?
34