fundamental model for access access control & security · capabilities: correspond to...
TRANSCRIPT
1
Access Control & SecurityModels
Simone Fischer-HübnerComputer Security 2008
Fundamental Model for Access Control
Subject Access request
ReferenceMonitor
(access controlpolicy)
Object
Access operations in Unix
Directory searchExecuting a program file
execute
Create or rename a file in the directory
Writing to a filewrite
List directorycontents
Reading from a file
read
Applied to directories
Applied to filesAccess operation
Grouping of entities
It is simpler to define access control
policies with:
� Groups (sets of users)
or
� Roles (sets of application-specificoperations)
DAC & MAC (1)
Discretionary Access Control (DAC):
� Subjects (e.g. users) at their own discretion can specify to the system who can access their objects (e.g. files)
� Restriction of access to objects based on the identity of the subject/ or subject-group
Drawback:
DAC is, by its nature, subject to Trojan Horse Attacks
DAC compromisd by Trojan Horse
Alice
GAME.exe(Trojan)
executes
Access Control entries for Alice’s file Secret.dat:
read, writeAlice
modifies
..... ....
Secret.dat
owns
Eve read
2
DAC & MAC (2)
Mandatory Access Control (MAC):
� Users and files have fixed security attributes that are used by the system to determine whether a user can access a file
� Security attributes are set by security administrator or automatically by the system
� Security attributes cannot be modified by users or their programs
DAC & MAC (3)
Example: Military (Multi-level) Security Policy:� Security levels that are in a linear or partial order are taken
as security attributes� Security levels of subjects are called clearances� Security levels of objects are called classifications
A subject S may read object O, if:clearance (S) > classification (O)
Subject S may write-access object O, ifclearance (S) < classification (O)
(see Bell LaPadula-Model)
Access Control Structures (1)
Access Control Matrix:S: set of subjectsO: set of objectsA: set of access operations
M = (Mso)s∈S, o∈O with Mso ⊂ A.
Example:
{execute, read, write}{execute}{read, write}Bill
{execute, read}{execute}-Alice
Fun.comEdit.exeBill.doc
Abstract concept, not suitable for direct implementations
Access Control Structures (2)
Access Control Lists (ACL):� Corresponds to a column of the access control matrix� Stores access rights to an object with the object itself� Typically used to protect owned objects such as files
Directory entries
Fun.com
Fun.com
Alice
Bob
execute, read
execute, read, write
ACL
Problems:Difficult to get an overview of permissions given to an individual user
Access Control Structures (3)
Capabilities:� Correspond to subjects’ rows in the access control matrix� Unforgeable tokens that specify the holders’ (subjects’) access rights� Typically associated with DAC� Suitable for distributed systems
Alice’s capability: edit.exe: execute; fun.com: execute, read
Bill’s capability: bill.doc: read, write; edit.exe: execute;
fun.com: execute, read, write
Problems:� Difficult to give an overview of who has permission to access a given
object� Difficult to revoke a capability� Special protection needed
New Paradigm: Certificate-based access control
� Today increasingly access requests to servers by remoteunknown users
� Traditional seperation between authentication and access control cannot be applied
� Digital certificates (or credentials) can be used to proveproperties of their holders (e.g., authorisations)
� Certificate issuer assigns authorisation to certificate holderthrough his signature
Alice’s public key, authorisation to use service X
Signed by issuer
3
Example: SPKI (Simple Public Key Format and Infrastructure) Certificates:
Digitally signed record which may be expressed as a 5-tuple (I, S, D, A, V) where
� I = public key or a hash of the public key of the certificate’s issuer
� S = subject acquiring the authority (typically its public key, hash of a public key)
� D = delegation bit indicating whether the subject has the right to further delegate the rights granted in this certificate
� A = authorisation field specifying the permissions granted by the issuer to the subject
� V = validity field of the certificate.
Purpose: to communicate permission from one keyholder to another
SPKI - Example
1) The bank wants to grant Alice on-line access to her account:
(KB, KA, yes, access to account X, always)signed by Bank
->with this certificate, Alice can access her account if she proves to hold the private key corresponding to KA.
2) Alice can give Carl the right to pay her bills while she is on vacation:
(KA, KC, no, access to account X for paying bills, vacation period) signed by Alice
->with the chain of the 2 certificates, Carl can pay the bills if he proves to hold the private key corresponding to KC.
KA: Alice’s public key
KB: The bank’s public key
KC: Carl’s public key
Security Models - Introduction
� Security Models needed to formulatesecurity policies
� Many security models are state machinemodels
State machine models (1)
State machine model: describes a system as an abstract mathematical state machine with:
� state variables representing the system state
� transition functions describing how the state variables (i.e. system state) change
State machine models (2)
Steps in developing a “secure” state-machine model:
1.) Define the security-relevant state variables (subjects, objects,
security attributes, access rights, etc.)
2.) Define the conditions for a secure state (“security properties”)
3.) Define state transition functions (e.g., create subject, create object, get access, revoke access)
4.) Prove that the functions maintain the secure state
5.) Define the initial state
6.) Prove that the initial state is secure in terms of the definition of the secure state
=> By induction it can be proven that every system state is secure
The Bell LaPadula Model(Mitre, 1973)
� Most famous security model
� State machine model
� Captures confidentiality aspects of access control
� Prevents information to flow ”downwards”from a high to a low security level
4
The Bell LaPadula Model –State variables
Variables:
� a set of subjects S
� a set of objects O
� a set of access operations A = {e:execute, r:read, a:append, w:write}
� a set of L of security levels with a partial ordering <
The Bell LaPadula Model –Access rights
xxalter
xxobserve
w:writer:reada:appende: execute
Access modes
Access rights
Bell LaPadula Model –Security Levels (1)
Security Levels contain of linearly ordered classifications:
unclassified
confidential
secret
top secret
However: Linearly ordered classifications alone are not expressive enough:
E.g. they cannot restrict access to a ”secret” project X just to the persons working on X (”need-to-know”).
Security level = (classification, set of categories)
Classifications: C1, C2, C3, C4,… (used to enforce least privilege)with C1 < C2 < C3 < C4 (linear order)
e.g.: unclassified < confidential < secret < top secret
Categories: K1, K2, K3, ...(used to enforce need-to-know)
e.g. Nuclear, Nato, Crypto
Example of a security level: (secret, {Nato, Crypto})
The Bell LaPadula Model –Security Levels (2)
For enforcing the ”need-to-know” principle, security levels also contain a set of categories:
The Bell LaPadula Model –Security Levels (3)
Security level-1 : (class-1, category-set-1)> (“dominates”)
Security level-2 : (class-2, category-set-2)⇔
class-1 > class-2 ∧ category-set-1 ⊇ category-set-2
Example:(top secret, {Nato, Crypto}) > (secret, {Nato})
The Bell LaPadula Model –Security Levels (4)
The relation “>“ (“dominates”) is a partial ordering: It is(1) reflexiv: Lu > Lu
(2) antisymmetric: Lu > Lv ∧ Lv > Lu ⇒ Lu = Lv
(3) transitive: Lu > Lv ∧ Lv > Lw ⇒ Lu > Lw
for levels Lu, Lv, Lw
Remark: A mistake you might make is to assume:If not (Lu > Lv ) then Lv > Lu.
Partially ordered security levels could be incomparable, e.g.:
(secret, {Nato}), (top secret, {Crypto})
5
Bell LaPadula Model –Security Levels (5)
� Partially ordered security levels form a lattice.� Example: Security levels composed of
� Classifications: private, public� Categories: PER (personnel), ENG (engineering)
public, Ø
Public, {PER, ENG}
private, Ø
private, {PER, ENG}
Public, {ENG}Public, {PER}
private, {PER} Private, {ENG}
The Bell LaPadula Model –System state
� System state captures all currentpermissions and all current instances of subjects accessing objects
� System state: (b, M, f)
� b: set of current accesses
� M: Access permission matrix
� f: Security Level function
The Bell LaPadula Model –Current access set
Current access set b:
Set of tuples (s, o, x),
indicating that subject s currently performsoperation x on object o.
The Bell LaPadula Model –Access permission matrix
Access permission matrix M:The component MSO records the access rights with which subject s is permitted to access object o (according to Bell LaPadula’s discretionary access control policy)
Subjects
Objects
MSO
S
O
r
The Bell LaPadula Model –Security Level function
Security level function f: (fS, fO, fC)
fs: S � L gives the maximal security level eachsubject can have,
fc: S � L gives the current security level of eachsubject (fc < fs),
fo: O � L gives the security levels of all objects.
The Bell LaPadula Model –Simple security property
Conditions (”properties”) for a secure state:
Simple security (ss)- property (”no read-up”):
If (s, o, x) ∈ b, x ∈{r, w} =>
fO(o) < fS(s).
Subject
Object
High
Low
readSecurity level
6
Illegal information flow not addressedby simple security-property
High
Low
Securitylevel
Subject-1 (malicious)
Subject-2
Object-1
Object-2
Illegal Information Flow !
observe
alter
observe
The Bell LaPadula Model –*-property (1)
*-Property (”no write-down”):
If (s, o1, x1) ∈ b, x1 ∈ {r, w}
and (s, o2, x2) ∈ b, x2 ∈ {a, w} =>
fO(o2) > fO(o1)
The Bell LaPadula Model –*-property (2)
The *-property can be refined in terms of the current security level:
If (s, o, x) ∈ b =>
fO(o) > fC(s) if x = a
fO(o) = fC(s) if x= w
fO(o) < fC(s) if x = r
The Bell LaPadula Model –*-property
� How can a high-level subject send a message to a low-level subject ?
� Temporarily downgrade current securitylevel
� Exeptions from *-property for ”trustedsubjects”
The Bell LaPadula Model –ds-property
Discretionary Security (ds) -Property:If (s, o, x) ∈ b ⇒ x ∈ Mso.
Simple security- and *-properties are enforced by Mandatory Access Control (MAC)
ds-property is enforced by Discretionary Access Control (DAC)
The Bell LaPadula Model –Secure state transitions (1)
A state is called secure if simple security-, *-, and ds- properties are satisfied
A state transition from state
v1 = (b1, M1, f1) to state v2 = (b2, M2, f2)
is secure, if v1 and v2 are secure.
7
The Bell LaPadula Model –Basic security theorem
”Security” in terms of the security propteriescan be guaranteed, if:
the initial state is ”secure”
all state transitions are ”secure”
(=> every subsequent state will be ”secure”)
Excercise
What kind of access can a process with the current security level (secret, {NATO, CRYPTO}) have to documents classified in each of the following ways under the Bell LaPadula Model:
1.(top secret, {NATO })2.(unclassified, {CRYPTO, NATO})3.(top secret, {CRYPTO, NUCLEAR})4.(secret, {NUCLEAR, CRYPTO})5.(top secret, {NATO, CRYPTO, NUCLEAR})
Bell LaPadula Model –Discussion
� Only deals with confidentiality, not with integrity
� ”blind write” might cause integrity problems
� Exposed to covert channel attacks
� Implemented in Multics, Unix V/MLS, Trusted Oracle,....
Integrity Models
Integrity Goals:
� Data consistency (validity of data)
� Preventing unauthorised users from making modifications
� Preventing authorised users from making improper modifications
Biba Integrity Model (1977)
First Integrity Model, dual to Bell LaPadula
Model elements:S: set of subjectsO: set of objectsI: set of integrity levels (il) with a partial ordering
Access modes: o (observe), m (modify), i (invoke)
Biba Model – ”no read down”Security properties:
Simple Integrity-Property (“no read down”):∀s ∈ S, o ∈ O: s o o ⇒ il(s) ≤ il(o)
Subject
Object-1
High
Low
observe
Integrity level
Object-2modify
8
Biba Model – ”no write up”
Integrity *-Property (”no write up”):∀s ∈ S, o ∈ O: s m o ⇒ il(o) ≤ il(s)
Subject
Object
High
Low
modifyIntegrity level
Biba Model –invocation property
Invocation Property:∀s1, s2 ∈ S: s1 i s2 ⇒ il(s2) ≤ il(s1)
Subject-1
High
Low
Integrity level
Subject-2
invoke
Biba Model - Discussion
� Does not address data consistency
� Only prevention of modifications by
unauthorized users
� Authorized users can still make improper
modifications
� Problem to assign appropriate integrity levels
� Only implemented in few systems
Clark Wilson Integrity Model (1988):
Policy is based on two key concepts:
� Well-formed transactions
� Separation of duties
Clark Wilson –Model Description
State variables:
CDIs: Constrained Data Items
IVPs: Integrity Verification Procedures
TPs: Transformation Procedures
(transaction = transformation procedure +
permitted CDIs)
UDIs: Unconstrained Data Items (input data)
Clark Wilson - Rules
Two types of rules:
� Certification Rules (C) - performed by the security officer
� Enforcement Rules (E) - done by the system
9
Clark Wilson - Overview
TP TP
UDI
CDI
CDI CDI
CDI
CDI
CDI
CDI
IVP
IVP
.......
LogCDI
LogCDI
LogCDI
ACCESS TRIPLES
(UserID, TP-i, (CDI-a, CDI-b,...), …)
USER
SECURITY OFFICER
Valid Initial StateValid next state Valid final state
C1
C1
E4
C5
E3
E1
E2
C4
C3
C2
C2
ACCESS TRIPLES
(UserID, TP-i, (CDI-a, CDI-b,...), …)
SECURITY OFFICER
E4
Clark Wilson –Certification Rules
TPs validate UDIC5:
TPs write logC4:
Suitable separation of dutiesC3:
TPs preserve valid stateC2:
IVPs certify CDI are validC1:
Clark Wilson –Enforcement Rules
Authorisation lists (Access Triples) changed only by security officer
E4:
Users are authenticatedE3:
Users are authorized for TPsE2.
CDIs changed only by authorized TPsE1:
Clark Wilson - Discussion
� Access triples can
� prevent modifications by unauthorized users
� enforce separation of duties
� Separation of Duties Principle can prevent
authorized users from making improper
modifications
� IVPs and TPs can help to guarantee consistency
Role-Based Access Control (RBAC) - Introduction
� Developed at NIST/NSA since early nineties
� American National Standard - ANSI INCITS 359-
2004
� Implemented in SUN Solaris, SELinux, Oracle,
Sybase,...
See also: http://csrc.nist.gov/rbac/
Role-Based Access Control (RBAC) - Approach
Security administrator assigns:
� Membership of users to roles: user --> roles
� Privileges (operations) to a role:
role --> set of operations
10
RBAC - Example
A user in the role “doctor” may perform the following transactions:
� enter_diagnosis
� prescribe_medication
Doctor
Patient Record
Prescription
Objects Roles Users
Dr. Sara John
Dr. Peter Smithenter_diagnosis
prescribe_med
Operations
member_of
member_of
RBAC – Access rules
A subject S may access an object O with
operation op if
� S performs a role r
� S is authorised to perform r
� r is allowed to perform op
� op is allowed to access O
RBAC –Reduced Administrative Overhead
� Allocation of operations to a role remains relatively constant or changes slowly over time.
� The security administrator’s task consists simply
of granting and revoking memberships to the set
of specified roles.
� Roles can be composed of roles with an
inheritance of privileges
RBAC – Role Hierarchies
Doctor
Patient Record
Prescription
Dr. Sara John
Dr. Peter Smithenter_diagnosis
prescribe_med
Nurse
member_of
enter_blood_values Mary Jo
Su Chen
Example: ”Doctor” role inherits privileges of ”Nurse” role
member_of
member_of
member_of
RBAC – Cost savings
Annual cost savings : $6.924 a year for 1.000 employees
RBAC – Further features (1)
� Static Separation of Duties� by defining mutually exclusive roles
� e.g. in a bank the roles ”teller”, ”auditor” cannotbe authorised for the same user
� Dynamic Separation of Duties� By defining mutually exclusive activation of roles
� e.g. Roles ”Payment Initiator”, ”PaymentAuthoriser” can be performed by same user, butnot at the same time
11
RBAC – Futher features (2)
� Role Cardinality
� by defining a capacity for a role
� e.g. only one user is ”Manager”
RBAC - Features in Commercial
Database Management Systems
YESYESYESGRANT DBMS Object Privileges to a role
YESYESNOGrant DBMS System Privileges to a role
NONONOSpecify maximum or minimum cardinality for role membership
NOYES(YES)Specify dynamic separation of duty constraints on roles
NOYESNOSpecify static separation of duty constraints on roles
YESYESYESBuild a role hierarchy
YESYESNOSpecify a default active role set for a user session
YESYESNOMultiple active roles for a user session
YESNOYESAbility for a role grantee to grant that role to other users
OracleSybaseInformixFeature
XACML - Standard
� ”eXtensible Access Control Markup Language” –OASIS Standard
� It describes:� General Purpose Access Control Language
� Access Control Decision Request/Response Protocol
(both written in XML)
� Advantages of XACML:� It’s standard - widely deployed, enables interoperability
� It’s generic – can be used in any environment, one policy can be used by many different applications
� It’s distributed – a policy can refer to other policies kept in arbitrary locations maintained by other groups/people
XACML - Components
� Policy Enforcement Point (PEP) – the system entity that performs access control(e.g. file system, web server)
� Policy Decision Point (PDP) – the system entity that evaluates applicable policies and renders an authorisation decision
� Policy Information Point (PIP) – the system entity that acts as a source of attribute values
� Policy Administration Point (PAP) – the system that creates a policy or policy set
How XACML is working
PEPAlice
”read file Y”System File Y
PDPXACML policies
PAP PIP
Decision request:Subject-id: Alice
Resource-id: File Y
Action-id: Read
Response:PermitObligation: recordin an audit log
AdditionalAttributes:
Role: Secretary,..
Time: 9am
Attributes, Authorities,…
XACML - Policy Structure
PolicySet
Target:
PolicySet applies if….
Policy
PolicySet
Policy
Target:
Policy applies if….
Rule
Rule
Target:
Rule applies if….
Effect:
If satisfied, rulereturns {permit, deny,
NotApplicable, Indeterminate}
Conditions:
Rule is satisfied if….
Set of simplifiedconditions for
subject, resourceand/or action
12
Example: A Simple XACML Rule
<Rule Effect=”Permit”>
<Target>
File Y
<\Target>
<Condition>
<Apply FunctionID=”AND”>
Role=”Secretary”,
Action=”Read”,
Time > 7am,
Time < 5pm,
….
<\Apply>
<\Condition>
<\Rule>
Conflict Resolution Policy (Meta Policy)
� Deny-overrides
� Permit-overrides
� …
Exercise 2
Consider the following commercial security requirements:
1. Users of applications (e.g. accounting) will use application programs and databases (i.e. read the application program code and read and write to the databases); they will not write their own programs to operate on the databases
2. Application program developer will do their development and testing in a test environment, and have no access to the application (source or object) programs or databases. They have access to programming tools and test data (i.e. they can read the programming tool code and read/write test data).
� Discuss if/how this requirement can be enforced by Bell LaPadula, Clark Wilson and RBAC