Flexible Support for Multiple Access Control Policies by Sushil Jajodia, Pierangela Samarati, Maria...
-
Upload
albert-quinn -
Category
Documents
-
view
214 -
download
0
Transcript of Flexible Support for Multiple Access Control Policies by Sushil Jajodia, Pierangela Samarati, Maria...
Flexible Support for Multiple Access Control PoliciesbySushil Jajodia, Pierangela Samarati, Maria Luisa Sapino, and V.S. Subrahmanian
Presented by: Rick Knowles14 April 2005
Agenda Problem Statement Components of a Flexible Authorization
Framework Authorization Specification and Policies Authorization Specification Language Architecture of the Authorization
Framework Materializing and Maintaining Derivation
and Decision Views Conclusions
Problem Statement System Security Officers require an
authorization model that can be used to restrict access to different classes of data objects May wish to use one policy to
regulate access to one type of object and a different policy for a different type of object
Possible Solutions When the protection requirements of an
application are different from the policy built into the system, implement a new policy in code Makes tasks of verification, modification, and
enforcement of the policy difficult Specification of negative authorizations
States accesses to be denied Limited in the access policies they can
express because they rely on a single underlying data model
Our Solution: Flexible Authorization Framework (FAF)
Based on a language through which users can specify security policies to be enforced on specific accesses Allows specification of positive and
negative authorizations Incorporates notions of authorization
derivation, conflict resolution and decision strategies
Authorization Framework:What is it?
In general, it determines the circumstances under which a user may attempt to execute an access operation on a given data item.
Must answer the following questions: To what data items is the framework mediating
access and how are these data items organized? For what kinds of accesses does the framework
determine authorization privileges? How are the users/user groups organized? What types of roles may users adopt and under
what conditions may they adopt these roles? Who can administer accesses?
Architecture....
propagationpolicy
conflict resol.and decisionpolicy
integrityconstraints
authorizationtable
historytable
granted/denied(o, s, +a)
.
.
.
.
Access control is enforced with respect to the user’s id, if no role is active, and with respect to the role if a role is active
For any access, exactly one decision (allowed / denied) is provided
Policies are expressed by a tightly restricted class of logic programs
Components:Intuitive Definitions Object/Type Items
Example of a directory structure
jim ed val mom dad sis jim ed val a.gif b.gif c.jpg d.jpg
univ personal staff faculty gif jpg
Mail accts images
Example of an OO structure
f1 f2 f3.doc f4.doc f5.htm f6.gif f7.gif f8.tiff f9.tiff f10.mpg f11.au
ascii word html gif tiff video audio
text image other
Components:Intuitive Definitions (cont)
Access types Actions or operations that the user tries
to execute on different data objects read, write, move, copy…
User and User Groups Groups are named sets of users
Jim Mary Jeremy George Lucy Mike Sam
CS-Faculty
Citizens CS-Dept Eng-Dept Non-Citizens
Public
Components:Intuitive Definitions (cont)
Roles Users assume roles Privileges apply only while user is
acting in the role Named collections of privileges
Secretary Dean Chair Faculty Researcher
Adm-Staff Research-Staff
Employee
Components:Formal Definitions - Hierarchy
A hierarchy is a triple (X, Y, ) where: X and Y are disjoint sets is a partial order on (X U Y) such that each x X is
a minimal element of (X U Y); an element x X is said to minimal iff there are no elements below it in the hierarchy, that is iff y (X U Y); y x y = x.
Object/Type hierarchy is the triple OTH=(Obj,T,OT) User/Group hierarchy is the triple UGH=(U,G,UG) Role hierarchy is the triple RH =(,R,R)
Two hierarchies H1=(X1,Y1,1) and H2=(X2,Y2,2) are disjoint iff (X1 U Y1) (X2 U Y2) =
Components:Formal Definitions - Data System
A data system consists of users/groups, the data they are accessing, together with the roles they may play and the types of access modes they use
A Data System (DS) is a 5-tuple (OTH, UGH, RH, A, Rel) where:
OTH=(Obj,T,OT) is an object-type hierarchy; UGH=(U,G,UG) is a user-group hierarchy; RH is a role hierarchy RH =(,R,R); A is a set whose elements are called authorization modes
or actions; Rel is a set whose elements are called relationships.
Relationships can be defined on the different elements of DS and may be unary, binary or n-ary in nature.
Authorizations:Authorization Hierarchies
Authorization Subject Denotes those entities for which authorization privileges
can be specified Authorization Subject Hierarchy (ASH)
Let DS=(OTH,UGH,RH,A,Rel) be a data system. ASH=(U,G U R, AS), where AS is defined as follows: x AS y iff {x,y} U U G & x UG y or {x,y} R & x R y
Intuitively, the graph of ASH is obtained by placing the graphs of UGH and RH side by side.
Jim Sec Mary Sec Jeremy Dean George Chair Lucy Researcher Mike Faculty Sam Faculty
CS-Faculty Research
Citizens Adm-Staff CS-Dept Research Eng-Dept Research Non-Citizens Employee
Public Employee
Authorizations:Authorization Hierarchies (cont)
Authorization Object Hierarchy (AOH) Let DS=(OTH,UGH,RH,A,Rel) be a data system.
AOH=(Obj,T U R, AO), where AO is defined as follows: x AO y iff {x,y} Obj U T & x OT y or {x,y} R & x R y
Intuitively, the graph of AOH is obtained by placing the graphs of OTH and the inverse of RH side by side.
jim ed val mom dad sis jim ed val EMPLOYEE
Univ Adm-Staff personal Adm-Staff staff Adm-Staff faculty Faculty
Mail Secretary accts Dean
Authorizations:Definition of Authorization
Definition: An authorization is a triple of the form (o,s,(sign)a) where o AO, s AS, a A and sign is either “+” or “-”
Examples (mail, faculty, +read) (personal, faculty, -read)
Logical question: How should authorizations be propagated? Other logical question: How should conflict
resolution be managed?
Authorizations:Propagation Policies
G1 (o, +a)
(o, -a) G2
G5
G3 G4(o,-a)
G6(o,-a)
u1 u2
R = AUTH =
{(o,G1,+a), (o,G2,-a), (o,G4,-a), (o,G6,-a)}
Why do we need a propagation policy? To expand a partial labeled hierarchy
It is a map that, given a hierarchy H and an input set of AUTH of authorizations, returns as output a set AUTH’ AUTH
Authorizations:Propagation Policies (cont)
No propagation AUTH’ = AUTH x X U Y:(z,+a) H
AUTH’ (x) (z,+a) HAUTH (x)
(z,-a) HAUTH’ (x) (z,-a) H
AUTH (x)
G1 (o, +a)
(o, -a) G2
G5
G3 G4(o,-a)
G6(o,-a)
u1 u2
R = AUTH =
{(o,G1,+a), (o,G2,-a), (o,G4,-a), (o,G6,-a)}
Authorizations:Propagation Policies (cont)
No overriding All authorizations are propagated to
the subnodes x X U Y:(z,+a) H
AUTH’ (x) y X U Y, x y, (z,+a) H
AUTH (y)
(z,-a) HAUTH’ (x) y X U Y, x y, (z,-
a) HAUTH (y)
G1 (o, +a)
(o, -a) G2
(o,+a)
(o,-a) u1
(o,+a)
G3 (o, +a) G4(o,-a) (o,+a)
G6(o,-a) (o, +a)
u2(o,-a) (o,+a)
R = AUTH =
{(o,G1,+a), (o,G2,-a), (o,G4,-a), (o,G6,-a)}(o,-a)
G5
(o,+a)
Authorizations:Propagation Policies (cont)
Most specific overrides Authorizations to a node are propagated to
subnodes if not overridden x X U Y:(z,+a) H
AUTH’ (x) y, w X U Y, y=w, x y, x w y, (z,+a) H
AUTH (y), (z,-a) HAUTH (w)
x X U Y:(z,-a) H
AUTH’ (x) y, w X U Y, y=w, x y, x w y, (z,-a) H
AUTH (y), (z,+a) HAUTH (w)
G1 (o, +a)
(o, -a) G2 G3 (o, +a) G4(o,-a)
G6(o,-a)
u2(o,-a)
R = AUTH =
{(o,G1,+a), (o,G2,-a), (o,G4,-a), (o,G6,-a)}(o, -a) G5
(o, -a) u1
Authorizations:Propagation Policies (cont)
Path overrides Authorizations of a node are propagated to subnodes
if not overridden. The label attached to a node n overrides a contradicting label of a supernode n’ for all the subnodes of n only for the paths passing from n
x X U Y:(z,+a) H
AUTH’ (x) y,p,w X U Y, y=w, p is a path between x and y in H, w appears in p, (z,+a) H
AUTH (y), (z,-a) H
AUTH (w) x X U Y:(z,+a) H
AUTH’ (x) y,p,w X U Y, y=w, p is a path between x and y in H, w appears in p, (z,+a) H
AUTH (y), (z,-a) H
AUTH (w)
R = AUTH =
{(o,G1,+a), (o,G2,-a), (o,G4,-a), (o,G6,-a)}
G1 (o, +a)
(o, -a) G2 G3 (o, +a) G4(o,-a)
G6(o,-a)
u2(o,-a)
(o, -a) G5
(o, -a) u1
(o,+a)
Authorizations:Conflict Resolution Policies
Obviously, the propagation policies potentially propagate conflicts. Some of the conflict resolution policies include: No conflicts
This policy assumes no conflicts. If one occurs, an error is generated.
Authorizations:Conflict Resolution Policies (cont)
Denials take precedence Negative authorizations are always
adopted when conflict occurs. For example, using the Path Overrides
example:G1 (o, +a)
(o, -a) G2 G3 (o, +a) G4(o,-a)
G6(o,-a)
u2(o,-a)
(o, -a) G5
(o, -a) u1
(o,+a)
G1 (o, +a)
(o, -a) G2 G3 (o, +a) G4(o,-a)
G6(o,-a)
u2(o,-a)
(o, -a) G5
(o, -a) u1
(o,+a)
Authorizations:Conflict Resolution Policies (cont)
Permissions take precedence Positive authorizations are always
adopted when conflict occurs. For example, using the Path Overrides
example:G1 (o, +a)
(o, -a) G2 G3 (o, +a) G4(o,-a)
G6(o,-a)
u2(o,-a)
(o, -a) G5
(o, -a) u1
(o,+a)
G1 (o, +a)
(o, -a) G2 G3 (o, +a) G4(o,-a)
G6(o,-a)
u2(o,-a)
(o, -a) G5
(o, -a) u1
(o,+a)
Authorizations:Conflict Resolution Policies (cont)
Nothing take precedence Neither authorize nor deny an access when
conflict occurs. Instead, defer to Decision Policies For example, using the Path Overrides example:
G1 (o, +a)
(o, -a) G2 G3 (o, +a) G4(o,-a)
G6(o,-a)
u2(o,-a)
(o, -a) G5
(o, -a) u1
(o,+a)
G1 (o, +a)
(o, -a) G2 G3 (o, +a) G4(o,-a)
G6(o,-a)
u2(o,-a)
(o, -a) G5
(o, -a) u1
(o,+a)
Authorization Specification Language:Constant and Variable Symbols
Every member of Obj U T U U U G U R U A U SA Obj is the set of objects. Variable: VO
T is the set of types. Variable: VT
U is the set of users. Variable: VU
G is the set of groups. Variable: VG
R is the set of roles. Variable: VR
A is the set of signed actions. Variable: VA
SA is the set of unsigned actions. Variable: VSA
Authorization Specification Language:Predicate Symbols
cando Authorizations explicitly inserted by SSO cando(file1,john,+read)
dercando Authorizations derived by the system using logic rules dercando(file1,john,-write)
do Represents the accesses that must be granted or
denied. Enforces conflict resolution and access decision policy
do(file2,bill,+write)
Authorization Specification Language:Other Predicate Symbols done: done(o,u,r,a,t) is true if user u with role r active has
executed action a on object on at time t overAO and overAS: used in definition of the overriding
policies error: signals the violation of the integrity constraints hie-predicates
in: captures ordering relationships in AOH and ASH dirin: captures direct membership relationships in AOH and
ASH Rel-predicates
owner: associates unique user or role with object isuser, isgroup, isrole: used for propagation, conflict
resolution or decision policies
Architecture....
propagationpolicy
conflict resol.and decisionpolicy
integrityconstraints
authorizationtable
historytable
granted/denied(o, s, +a)
.
.
.
.
Access control is enforced with respect to the user’s id, if no role is active, and with respect to the role if a role is active
For any access, exactly one decision (allowed / denied) is provided
Policies are expressed by a tightly restricted class of logic programs
Architecture:History Table
Rows describe the accesses executed
Useful in implementing policies in which future accesses are based on accesses each user has made in the past (i.e., Chinese Wall policy)
done(object, user, role, action, time)
Architecture:Authorization Table
Viewed as a database Rows are authorizations
(o,s,<signed>a) Example:
cando(file1,s,+read) in(s,Employees,ASH) & in(s,Soft-Developers,ASH)
cando(file2,s,+read) in(s,Employees,ASH) & in(s,Non-citizens,ASH)
Architecture:Propagation Policy
Specifies how to obtain new derived authorizations from the explicit Authorization Table
Example dercando(file1,s,-write) dercando(file2,s,read) dercando(o,s,-grade) done(o,s,r,write,t) &
in(o,Exams,AOH) dercando(file1,s,-read) dercando(file2,s’,read)
& in(s,g,ASH) & in(s’,g,ASH)
Architecture:Conflict Resolution and Decision Policy
Specifies how to eliminate conflicts from conflicting authorizations
Determines the system’s response (yes or no) to every possible access request
Examples do(file1,s,+a) dercando(file1,s,+a) do(file2,s,+a) dercando(file2,s,-a) do(o,s,+read) dercando(o,s,+read) &
dercando(o,s,-read) & in(o,Pblc-docs,AOH)
Architecture: Integrity Rules
Imposes restrictions on the content and output of the other components
Derives an error every time the conditions on the right hand side of the equation are satisfied
Examples error in(s,Citizens,ASH) & in(s,Non-
citizens,ASH) error cando(o,s,+a) & cando(o,s,-a) error do(o,s,+write) & do(o,s,+evaluate) &
in(o,Tech-reports,ASH)
ArchitectureTying it all together Putting this all together, the SSO creates an
Authorization Specification (AS) Components
History table Authorization table Set of integrity rules hie-, rel-, and overriding predicates Derivation view Decision view
Authors developed proofs to show that the AS is a unique, stable model and that for any attempt to do action a by user s on object o, exactly one of do(o,s,+a) or do(o,s,-a) is true
Authorization Specification StrataLevel Stratum Predicate Rules defining predicate
0 AS0 hie-predicaterel-predicatedone
Base relationsBase relationsBase relation
1 AS1 cando Body may contain done, hie- and rel- literals
2 AS2 dercando Body may contain cando, dercando, done, hie-, and rel- literals. Occurrences of dercando literals must be positive
3 AS3 do In the case when head is of the form do(-,-,+a), body may contain cando, dercando, done, hie- and rel- literals
4 AS4 do In the case when head is of the form do(-,-,-a), body may contain just one literal !do(o,s,+a)
5 AS5 error Body may contain do, cando, dercando, done, hie- and rel- literals.
Materialization Structure The end goal, of course, is to create a
system that answers the question, “Can user s do action a on object o?” The proofs on AS show it can be done, but
the question is how fast? Two goals:
Request should be authorized or denied very fast Changes to the specifications are far less frequent
than access requests
Materialized Views Their answer is to develop materialized
views of the derivation and decision views Not the entire AS Just the association of each fact of the model
with the indexes of the rules that directly support its truth
Construction is an iterative process based on the AS stratum
Derivation view is AS2 Decision view is AS3
Computation of model is polynomial data complexity Computation of updates to the model are also of
polynomial data complexity
Conclusions Traditionally, most systems implement a single access
control policy The FAF approach provides the application developer
with a host of policy options SSO specifies access control requirements through explicit
authorizations together with derivation, conflict resolution and decision strategies
Different strategies may be applied to different users, groups, objects, or roles
Further work Extend model that regulate different insertions by multiple
users (not just one SSO) Extend model to represent and enforce complex security
policies of different organizations