Parameterized Verification goes Safety Analysis of Access Control Policies Silvio Ranise , Riccardo Traverso, Anh Truong FBK-Irst, Trento, Italy Metodi dichiarativi nella verifica di sistemi parametrici Milano, 25-26 Settembre, 2014 Ranise (FBK) Parameterized Safety Analysis of AC Policies DMUM 1 / 40
Access Control The process of ◮ mediating requests to resources and data maintained by a system and ◮ determining whether a request should be granted or denied Crucial role in system security Usually separation between ◮ policies specified by a language with an underlying model ◮ mechanisms enforcing policies Separation implies ◮ protection requirements are independent of their implementation ◮ analysis of policies can be done abstractly Ranise (FBK) Parameterized Safety Analysis of AC Policies DMUM 2 / 40
The naive approach to access control User Permission Alice GrantTenure Alice AssignGrades Alice ReceiveHBenefits Alice UseGym Bob GrantTenure Bob AssignGrades Bob UseGym Charlie GrantTenure Charlie AssignGrades Charlie UseGym David AssignHWScores David Register4Courses David UseGym Eve ReceiveHBenefits Eve UseGym Fred Register4Courses Fred UseGym Greg UseGym Ranise (FBK) Parameterized Safety Analysis of AC Policies DMUM 3 / 40
Better: Role-based Access Control (RBAC) role = indirection between users and permissions a role corresponds to a job function and/or qualifications users are made members of roles Ranise (FBK) Parameterized Safety Analysis of AC Policies DMUM 4 / 40
RBAC: basic model Permission Assignment (PA) Role Permission PCMember GrantTenure PCMember AssignGrades User Assignment (UA) PCMember ReceiveHBenefits User Role PCMember UseGym Alice PCMember Faculty AssignGrades Bob Faculty Faculty ReceiveHBenefits Charlie Faculty Faculty UseGym David TA TA AssignHWScores David Student TA Register4Courses Eve UEmployee TA UseGym Fred Student UEmployee ReceiveHBenefits Greg UMember UEmployee UseGym Student Register4Courses Student UseGym UMember UseGym Ranise (FBK) Parameterized Safety Analysis of AC Policies DMUM 5 / 40
An even better approach: RBAC + role hierarchy role = indirection between users and permissions a role corresponds to a job function and/or qualifications users are made members of roles roles are organized in a role hierarchy “more senior than” relation permission “inheritance” Ranise (FBK) Parameterized Safety Analysis of AC Policies DMUM 6 / 40
RBAC + role hierarchy Permission Assignment (PA) Role Permission PCMember GrantTenure Faculty AssignGrades TA AssignHWScores User Assignment (UA) UEmployee ReceiveHBenefits User Role Student Register4Courses Alice PCMember UMember UseGym Bob Faculty Charlie Faculty David TA David Student Eve UEmployee Fred Student Greg UMember Role Hierarchy ( � ) Ranise (FBK) Parameterized Safety Analysis of AC Policies DMUM 7 / 40
Administration of Access Control Policies In a large, possibly distributed, system (e.g., Dresdner bank: 40,000 users and 1,400 permissions), a single security officer cannot administer the entire system Several security officers ◮ One the one hand, offer the flexibility and scalability to cope with large, complex, and distributed systems ◮ On the other hand, imply reduced control and security: ⋆ arbitrary modifications of policies can give untrusted users access permissions to sensitive resources ⋆ to what degree can we trust administrators ? SOLUTION : administrative modification of policies is subject to constraints Ranise (FBK) Parameterized Safety Analysis of AC Policies DMUM 8 / 40
Constrained Administration of RBAC policies: ARBAC Only certain administrators can perform a given set of permitted administrative actions: ◮ assigning a role to a user ◮ revoking a role from a user Conditions on the execution of administrative actions: administrative domains identifying administrators that can take the responsibility to execute an action on certain users In the literature, several ways to define administrative domains Most popular: administrative domains as (combinations of) roles In other words: use RBAC policies to regulate modifications to RBAC policies Ranise (FBK) Parameterized Safety Analysis of AC Policies DMUM 9 / 40
The ARBAC Model R. Sandhu, V. Bhamidipati, and Q. Munawer. The ARBAC97 Model for Role-Based Administra- tion of Roles. ACM Transactions on Information and System Se- curity (TISSEC), 2(1): 105-135, Feb. 1999. Ranise (FBK) Parameterized Safety Analysis of AC Policies DMUM 10 / 40
The ARBAC Model: overview Administrative actions: C a | C → r assigning role r to a user in the administrative domain ◮ C can be performed by administrator in domain C a C a → r revoking role r from a user assigned to it can be ◮ performed by an administrator in domain C a What are C and C a ? Finite sets of signed roles: ◮ positive: + r (requiring user/admin. belongs to r ) ◮ negative: − r (requiring user/admin. does not belong to r ) Meaning: ◮ C = { + r 1 , + r 2 , − r 3 } requires user assigned to r 1 and r 2 but not to r 3 ◮ C a = {− r 1 , + r 4 } requires administrator assigned to r 4 but not to r 1 Ranise (FBK) Parameterized Safety Analysis of AC Policies DMUM 11 / 40
Ranise (FBK) Parameterized Safety Analysis of AC Policies DMUM 12 / 40
Ranise (FBK) Parameterized Safety Analysis of AC Policies DMUM 13 / 40
Ranise (FBK) Parameterized Safety Analysis of AC Policies DMUM 14 / 40
Ranise (FBK) Parameterized Safety Analysis of AC Policies DMUM 15 / 40
Ranise (FBK) Parameterized Safety Analysis of AC Policies DMUM 16 / 40
Observation Only the user-role assignment relation UA is modified since this, by design, is the one that is most frequently updated ... ... while the permission-assignment PA and the role hierarchy � are rarely changed This is standard in the literature about the analysis of ARBAC policies ... ... and also reasonable in practice Ranise (FBK) Parameterized Safety Analysis of AC Policies DMUM 17 / 40
Analysis of ARBAC Policies A. Sasturkar, P . Yang, S. D. Stoller, and C.R. Ramakrishnan. Policy Analysis for Administrative Role Based Access Control. Theoretical Computer Science 412(44):6208-6234, October 2011. Ranise (FBK) Parameterized Safety Analysis of AC Policies DMUM 18 / 40
Motivation Difficulties in considering ◮ all possible interleavings of permitted administrative actions (usually very large number for complex and distributed systems) ◮ the effect of changes to permitted administrative actions due to evolving requirements Need of push-button safety analysis techniques for both ◮ first-time and ◮ evolving administrative policies Ranise (FBK) Parameterized Safety Analysis of AC Policies DMUM 19 / 40
Analysis of ARBAC policies: safety Problem instance is identified by the following tuple: ( ι, ψ, ( u g , C g )) ι : initial RBAC policy ψ = can _ assign ∪ can _ revoke : permitted administrative actions ( u g , C g ) : goal formed by a user u g and a condition C g (set of signed roles) = ⇒ P SPACE -complete ! Ranise (FBK) Parameterized Safety Analysis of AC Policies DMUM 20 / 40
Meaning of the Safety Problem ( ι, ψ, ( u g , C g )) Does there exist a sequence of administrative actions that can be applied to the initial RBAC policy ι so as to obtain a new RBAC policy in which u g satisfies condition C g (i.e. u g is assigned to r if + r ∈ C g and is not assigned to r if − r ∈ C g ) ? Ranise (FBK) Parameterized Safety Analysis of AC Policies DMUM 21 / 40
Solving First-time Safety Problems S. Ranise. Symbolic backward reachability with effectively propo- sitional logic - Applications to security policy analysis. Formal Methods in System Design 42(1): 24-45 (2013) Ranise (FBK) Parameterized Safety Analysis of AC Policies DMUM 22 / 40
Our technique to solve first-time Safety Problems for ARBAC policies: ASASP ι : initial temporal RBAC policy ψ : all possible administrative actions (assigning/revoking roles) ( u , C ) : goal encoding the following question “can user u satisfy condition C ?” Answer: yes (reachable) / no (unreachable) Ranise (FBK) Parameterized Safety Analysis of AC Policies DMUM 23 / 40
Our technique to solve first-time Safety Problems for ARBAC policies: ASASP Translator Perform faithful symbolic encoding of safety problem: use first-order logic to represent initial RBAC policy ι and goal ( u , C ) by formulae 1 administrative actions ∈ ψ by formulae τ 1 , ..., τ n 2 goal ( u , C ) is reachable ⇐ ⇒ there exists k � 0 such that 3 Init ι ∧ τ i 1 ∧ · · · ∧ τ i k ∧ Goal ( u , C ) is satisfiable Ranise (FBK) Parameterized Safety Analysis of AC Policies DMUM 24 / 40
Example of translation Goal (? , { + r 1 , − r 3 } ) : ∃ u . ( r 1 ( u ) ∧ ¬ r 3 ( u )) r 3 ( a ) ∧ r 1 ( u ) ∧ ¬ r 4 ( u ) ∧ ∀ x . r ′ { + r 3 }|{ + r 1 , − r 4 } → r 2 : ∃ a , u . 2 ( x ) ⇔ (( x = u ) ∨ r 2 ( u )) ∧ ρ � = r 2 ∀ x .ρ ′ ( x ) ⇔ ρ ( x ) � r 1 ( a ) ∧ r 3 ( u ) ∧ ∀ x . r ′ 3 ( x ) ⇔ (( x � = u ) ∧ r 3 ( u )) ∧ { + r 1 } → r 3 : ∃ a , u . ρ � = r 3 ∀ x .ρ ′ ( x ) ⇔ ρ ( x ) � Initial RBAC empty: � ρ ∀ x . ¬ ρ ( x ) Ranise (FBK) Parameterized Safety Analysis of AC Policies DMUM 25 / 40
Recommend
More recommend
