Security Fundamentals: Models
Trent Jaeger
January 12, 2004
Trent Jaeger -- Background

Graduated from UM with PhD
–
–

Flexible Control of Downloaded Executable Content
Research Thread That Led to Java 2 Security Model
IBM TJ Watson Research Center 1996-Present
–
Operating Systems Research 1996-2001


–
Systems Security Research 2001-Present




L4 microkernel-based systems: L4Linux, Lava, JavaOS, SawMill
Security policy: graphical access control, constraint models
Linux Security: based on the Linux Security Modules framework
Linux Security Analysis Project: source code and policy analysis –
www.research.ibm.com/vali
Conference chair, programming chair of ACM SACMAT, CCS
PC member of IEEE S&P, USENIX, ESORICS, etc.
Access Control





Determine whether a principal can perform
a requested operation on a target object
Principal: user, process, etc.
Operation: read, write, etc.
Object: file, tuple, etc.
Lampson defined the familiar access matrix
and its two interpretations ACLs and
capabilities [Lampson70]
Why are we still talking about access
control?


An access control policy is a specification for an
access decision function
The policy aims to achieve
–
–
Permit the principal’s intended function (availability)
Ensure security properties are met (integrity, confidentiality)


–
Limit to “Least Privilege,” Protect system integrity, Prevent
unauthorized leakage, etc.
Also known as ‘constraints’
Enable administration of a changeable system (simplicity)
“Simple” example

Prof Alice manages access to course objects
–
–
–
–

Prof Alice wants certain guarantees
–
–

Assign access to individual (principal: Bob)
Assign access to aggregate (course-students)
Associate access to relation (students(course))
Assign students to project groups (student(course, project, group))
Students cannot modify objects written by Prof Alice
Students cannot read/modify objects of other groups
Prof Alice must be able to maintain access policy
–
–
Ensure that individual rights do not violate guarantees
However, exceptions are possible – students may distribute their
results from previous assignments for an exam
Access Control is Hard Because

Access control requirements are domain-specific
–

Access control requirements can change
–

Anyone could be an administrator
The Safety Problem [HRU76]
–

Generic approaches over-generalize
Can only know what is leaked right now
Access is fail-safe, but Constraints are not
–
And constraints must restrict all future states
Compare to Other CS Problems

Processor design
–

Network protocol design
–
–

Hard, but can get some smart people together to construct
one, fixed, testable design
TCP: A small number of control parameters necessary to
manage all reasonable options, within a layered architecture
Constraints, such as DDoS, are ad hoc
Software design
–
Specific goals in mind to achieve function, constraints are
ad hoc
Reference Monitor Model
Entry Points
System
Interface
Access
Hook
Access
Hook
Authorize
Request?
Security-sensitive
Operation
Security-sensitive
Operation
Access
Hook
Security-sensitive
Operation
Monitor
Policy
Yes/No
Reference Monitor Components

Interface
–
–
–

Decision function
–
–

Where to make access control decisions (mediation)
Which access control decisions to make (authorization)
Linux Security Modules interface
Compute decision based on request and policy
E.g., SELinux, LIDS, DTE, etc. modules
Policy – our focus today
–
–
How to represent access control policy
Main mechanism issue – find mechanism to enable verification
that policy achieves function and meets security guarantees
Access Control Models

Basic Access Matrix
–

Aggregated Access Matrix
–

Bell-LaPadula, Biba, Denning
Predicate Models
–

DTE, SELinux, Java
Lattice Access Control Models
–

TE, RBAC, groups and attributes, parameterized
Plus Domain Transitions
–

UNIX, ACL, various capability systems
ASL, OASIS, domain-specific models, many others
Safety Models
–
Take-grant, Schematic Protection Model, Typed Access Matrix
Need for Aggregate Models (RBAC)

Practical ease of specification
–

Natural access control aggregations – based on
organizational roles
–
–


Abstraction for users, permissions, constraints,
administration
As new employees join, their permission assignments are
determined by their job
Permission assignment is largely static
Central control and maintenance of access rights
Flexible enough to enforce
–
least privilege, separation of duties, etc.
Type Enforcement [BoebertKain84]
Permission
Assignment
Object
User
User
User
Type
(Subject)
Subject Type Can
Access Object Type
To Perform Operations
On Objects
Type
(Object)
Object
Object
Group and Attributes
Permission
Assignment
Object
User
User
User
User
Group
User Group Has
Access To Objects
With the Attribute
Attribute
Object
Object
Role-based Access Control
User-Role Assignment
Perm-Role Assignment
Role
Perm
Object
Perm
Object
Perm
Object
User
User
User
Users in Role Can
Access Objects Using
Permissions
Role vs. Types Data Structures

RBAC
–
–

U: set of users
P: set of permissions
Type Enforcement
–
–
E: set of subjects or objects
Permission Assignment



ST: set of subject types
OT: set of object types
O: set of operations
Role-based Access Control Model







Users: U
Permissions: P
Roles: R
Assignments: User-role, perm-role, role-role
Sessions: S
Function: user(S), roles(S)
Constraints: C
RBAC Family of Models






RBAC0 contains all but hierarchies and constraints
RBAC1 contains RBAC0 and hierarchies
RBAC2 contains RBAC0 and constraints
RBAC3 contains all
The RBAC family idea has always been more a NIST
initiative
The RBAC families are present in the NIST RBAC
standard [NIST2001] with slight modifications:
–
RBAC0, RBAC1 (options), RBAC3 (SSD) , RBAC3 (DSD)
Hierarchies and Constraints

Role hierarchy
–
–

Constraints
–
–

Problem: does organizational hierarchy correspond to a
permission inheritance hierarchy?
Problem: do organizational roles make sense for building
hierarchies?
Problem: constraints apply to all states, so they require a predicate
calculus in general
Problem: Only certain types of constraints can effectively be
administered? Mutual exclusion, separation of duty, cardinality, etc.
Conflicts
–
May find other concepts useful for resolving conflicts between
constraints and hierarchies/assignments
Administration

Discretionary Access Control
–

Mandatory Access Control
–

Users (typically object owner) can decide
permission assignments
System administrator decides on permission
assignments
Flexible Administrative Management
–
Access control models can be used to express
administrative privileges
Does RBAC Achieve Its Goals?

Practical ease of specification
–

Natural access control aggregations – based on
organizational roles
–

In some cases, but not clear that organizational roles help
with permission assignment – particularly with inheritance
Central control and maintenance of access rights
–

Clear base model – need more help for constraints, admin
Central view is a selling feature of products, but a single
view of all can be complex (layering?)
Flexible enough to enforce
–
Flexible access control expression, but difficult to determine
if we enforce our security goals (constraints)
RBAC Products







SUN Solaris
Sybase SQL Server
BMC INCONTROL for Security Management
Systor Security Administration Manager
Tivoli TME Security Management
Computer Associates Protect IT
Siemens rbacDirX
Safety Problem [HRU76]

Determine if an unauthorized permission is leaked given
–
–

For a traditional approach, the safety problem is undecidable
–
–
–

An initial set of permissions and
An access control system, mainly administrative operations
Access matrix model with multi-operational commands
Main culprit is create – create object/subject with own rights
Prove reduction of a Turing machine to the multi-operational access
matrix system
Result led to
–
–
–
Safe, but limited models: take-grant, schematic protection model,
typed access matrix model
Further support for models in which the constraints are implicit in the
model – e.g., lattice models
Check safety on each policy change – constraint approach of RBAC
Lattice Access Control Models


Subjects and Objects have security levels and
optional categories
Confidentiality Policy (e.g., Bell-LaPadula)
–
–
–

Simple property: may read only if the subject’s security level
dominates the object’s security level (read-down)
*-property: may write only if the subject’s security level is
dominated by the object’s security level (write-up)
Tranquility property: may not change the security level of an
object concurrent to its use
Integrity Policy
–
Biba is the dual of BLP for integrity
Security Levels and Policies
Read/write
Read/write
Dominance
1>2>3
L:1
Read
BLP Operations
Biba Operations
Write
L:2
Write
Read
L:3
Purpose of BLP and Biba

BLP
–
–

Biba
–
–


Prevent Trojan horses from leaking information to lower security
levels
Mandatory access control and implicit constraints
Prevent low integrity information flows to higher integrity processes
E.g., code, configuration, user requests, buffer overflows
Categories/Compartments for separation within levels
Safety is implicit in the model
–
No additional constraints are needed to express security
guarantees
Denning’s Lattice Model

Formalizes information flow models
–

Shows that the information flow model instances form a lattice
–
–
–
–




FM = {N, P,SC,/,t}
{SC, t} is a partial ordered set,
SC is finite,
SC has a lower bound,
and / is a lub operator
Implicit and explicit information flows
Semantics for verifying that a configuration is secure
Static and dynamic binding considered
Biba and BLP are among the simplest models of this type
Implicit and explicit flows

Explicit
–

Implicit
–

Where value of b may depend on value of a indirectly (e.g.,
if a = 0, then b = c)
Model covers all programs
–
–
–

Direct transfer to b from a (e.g., b = a)
Statement S
Sequence S1, S2
Conditional c: S1, …, Sm
Implicit flows only occur in conditionals
Semantics

Program is secure if:
–
–
–
Explicit flow from S is secure
Explicit flow of all statements in a sequence are
secure (e.g., S1; S2)
Conditional c:S1, …, Sm is secure if:


The explicit flows of all statements S1, …, Sm are
secure
The implicit flows between c and the objects in Si are
secure
Static and Dynamic Binding

Static binding
–
–
–

Security class of an object is fixed
This is the case for BLP and Biba
This is the case for most system models
Dynamic binding
–
–
–
Security class of an object can change
For b = a, then the security class of b is b /
Rare approach
a
Model Examination

Static binding
–
BLP and Biba check security property at runtime



–
Guarantees security of all implicit and explicit flows
If a, then b = c means that a t b, so SC(a) must be dominated
by SC(b) in BLP
Otherwise, information leakage
Data Mark Machine




Security class depends on location in program
Combine with condition class on entering condition
Data flow captured because c t b is checked in condition and
b t a is checked outside and t is transitive
Does not hold for dynamic binding
Model Examination

Certification Mechanism
–
–
Static check eliminates covert channels
Limits



Language defect could miss a check (buffer overflow)
Hardware malfunction
Approach
–
Verify information flow w/i a statement

–
–
–
d = a + b; a / b t d; d must dominate
Set statement security level S = d
Statement sequence S = S11S2 – must be able to flow to
greatest lower bound
Verify c t d1, …, dn for implicit flow
Verification Example
d = PS
e = MS
et d X
TS
MS
PS
NS
d = TS
e = MS
e t d OK
S = S1 1 S2 = MS
c t S, c dominated by MS
Dynamic Binding

Definition
–

May change the security class of an object that removes it from
view – could leak covertly!
Dynamic Data Mark
–
–
Combine program class with actual data flow class
Static binding mechanism doesn’t work




paper example shows that dynamic class updating does not account
for implicit flows
Local object solution ensures correct classification, but seems
functionally limiting
Static analysis to insert classification statements to cover implicit flows
High Water Mark
–
–
Class is raised to prevent leakage a / b whenever b = a
Similar flaw to Dynamic Data Mark – and similar fix
Lattice Model Features

Safe policies w/o constraints
–
–

Bell-LaPadula is consistent with military security policy
Biba is not consistent with any practical integrity policy
Problem: Downgraders/Upgraders
–
Changing the security label of an object requires sanitization


–
–

Remove secrets for confidentiality downgrade
Remove low integrity data for integrity upgrade
Sanitization is ad hoc
Sanitizer must be of trusted (more stringent requirement than
simply being at the higher security class)
Lattice model effectiveness is limited by the number of
downgraders
Recent Information Flow Policies

Information flow in programming languages
–

Decentralized Label Model
–
–
–
–

Andrew Myers (Cornell), Steve Zdancewic (U Penn), Barbara
Liskov (MIT)
Flow policies of principals implemented by labeled data
System guarantees to enforce all policies simultaneously
Declassification enables remove of restrictions “where appropriate”
– determined by programmer
Enables static checking
Advantage: assume programmer is trusted to describe security
policies
–
Programmers can prevent Trojan horse leakage in downgrade
Decentralized Labels

Labels have owners and readers
–
–

Static binding
–

A new label contains the owners of the old, but fewer readers
Declassification semantics
–

Label of a value is forgotten when assigned to a variable
Relabeling semantics
–

L = {o1: r1, r2; o2: r2, r3}
Effective readers of L {r2} because only it can read from o1 and o2
An authority for an owner can add the owner or readers of the
owner
Label join/meet semantics
–
–
Join (e.g., multiply 2 numbers) Union owners and intersect readers
Meet (dual of join): Intersect owners and union readers?
Other Models

Plus Domain Transitions
–

Predicate Models
–

DTE, SELinux, Java
ASL, OASIS, domain-specific models, many
others
Safety Models
–
Take-grant, Schematic Protection Model, Typed
Access Matrix
References

(Ref monitor) Irvine, C.E., The Reference Monitor Concept as a
Unifying
Principle in Computer Security Education, Proceeding IFIP
TC11 WC 11.8 First World Conference on Information Security
Education , Kista, Sweden, June 1999, pp 27--37

(BLP) Bell-LaPadula: MITRE tech report – hard to find

(Denning) Dorothy E. Denning: A Lattice Model of Secure
Information Flow. Commun. ACM 19(5): 236-243 (1976)

(Biba) Biba, K. Tech report – hard to find

(TE) Boebert, W. E. and Kain, R. Y. 1985. A practical alternative
to hierarchical integrity policies. In Proceedings of the 8th
National Computer Security Conference (Gaithersburg, Md.).

(DTE) Badger, L., Sterne, D. F., Sherman, D. L., Walker, K. M.
and Haghighat, S. A. 1995. Practical Domain and Type
Enforcement for Unix. In Proceedings of the IEEE Symposium
on Security and Privacy.

(Myers) Myers, A.C., Liskov, B. Complete, Safe Information
Flow with Decntralized Labels. 1998. In Proceedings of the
IEEE Symposium on Security and Privacy.

(RBAC) Ravi S. Sandhu, Edward J. Coyne, Hal L. Feinstein,
and Charles E. Youman. Role-based access control models.
IEEE Computer, 29(2):38-47, February 1996.

(Information Flow) J. Goguen and J. Meseguer, Security
Policies and security models, In Proceedings of the 1982 IEEE
Symposium on Research in Security and Privacy, IEEE
Computer Security Press, 1982.

(ASL) S. Jajodia, P. Samarati, and V.S. Subrahmanian, A
Logical Language for Expressing Authorizations, Proc. of the
IEEE Symposium on Security and Privacy, Oakland, CA, 1997.

(OASIS) Jean Bacon, Ken Moody, Walt Yao: A model of OASIS
role-based access control and its support for active security.
ACM Trans. Inf. Syst. Secur. 5(4): 492-540 (2002)

(HRU) M.A. Harrison, M.L. Ruzzo, and J.D. Ullman. Protection
in operating systems. Communications of the ACM, 19(8):461-471, 1976.

(Take-Grant) Jones, A. K., Lipton, R. J., and Snyder, L., "A
Linear Time Algorithm for Deciding Security," Proc. 17th Annual
Symp. on Found. of Comp. Sci., 1976.
Descargar

Access Control Models - University of Michigan