Why We Should Take a Second What do we learn from Look at Access - - PowerPoint PPT Presentation

Introduction A model for Unix What do we learn from this? Concluding remarks

Why We Should Take a Second Look at Access Control in Unix

Jason Crampton

Information Security Group Royal Holloway, University of London

NordSec 2008

Introduction A model for Unix What do we learn from this? Concluding remarks

Disclaimer

This is not really a research talk, more of a thought experiment

◮ What can we learn about authorization by developing a

“formal model” for Unix

◮ What can we say about existing authorization models

having done this?

◮ How should we approach authorization in the future?

Introduction A model for Unix What do we learn from this? Concluding remarks

One-slide overview

◮ What is authorization? ◮ How do we model authorization in Unix? ◮ What do we learn from doing this? ◮ How should we design authorization models and how

should we implement those models?

◮ How do these questions relate to RBAC and XACML?

Introduction A model for Unix What do we learn from this? Concluding remarks

What is authorization?

An authorization service is a component of a computerized system that controls the interaction between users and resources

◮ An authorization service typically enforces a set of rules or

policies that define the permissible interactions

◮ Some group of users may be allowed to read a certain file,

whereas another group is allowed to read and modify the file

Introduction A model for Unix What do we learn from this? Concluding remarks

Authorization policy and authorization state

In the research community there seems to be some confusion between authorization policy and authorization state

◮ Both are required to decide whether a user request to

access a particular resource should be granted

◮ The same policy may result in different authorization

decisions given different states

◮ The same state may result in different authorization

decisions given different policies It is my thesis that this confusion leads to the development of poorly conceived models and implementations

Introduction A model for Unix What do we learn from this? Concluding remarks

The Chinese Wall policy

The policy

◮ Every file has an owner ◮ The set of owners are partitioned into conflict of interest

classes (CIC)

◮ A user u may read a file f belonging to owner o if u has

not read any file belonging to o′ = o in the same CIC Enforcing the policy

◮ Record all file accesses ◮ Evaluate new request with reference to access history for

requesting user The authorization state

◮ A record of all previous (successful) access requests ◮ Modeled as a “history matrix” by Brewer and Nash

Introduction A model for Unix What do we learn from this? Concluding remarks

An information flow policy

The simple security property (SSP) says that a user u is permitted to read object o if λ(s) λ(o)

◮ The state is defined by the set of users, objects, the

partially ordered set of security labels (L, ) and λ : S ∪ O → L

◮ An authorization decision is determined by the request

(read or not) and the state Hence, to decide whether a request satisfies the SSP, we must define a decision function

◮ Inputs: u, o, the requested action and (L, ) ◮ Output: boolean value

Introduction A model for Unix What do we learn from this? Concluding remarks

The protection matrix

The confusion between state and policy arises because of the protection matrix model

◮ All authorized access requests are encoded in a matrix ◮ A request is allowed if and only if it is present in the matrix

The policy in this case is trivial

◮ However, the configuration of a matrix (or equivalent

structure) has come to be seen as “policy”

◮ In some ways this is reasonable as it encodes the security

“policy” of an organization (assuming a simple rule for evaluating whether a “policy” is satisfied)

Introduction A model for Unix What do we learn from this? Concluding remarks

Two definitions

Definition

An authorization policy is a specification of a decision-making function that takes a request query and authorization state as inputs and returns an authorization decision

Definition

An authorization evaluation function is an implementation of an authorization policy To the research community, an “access control model” seems to comprise (confuse?)

◮ An abstract mathematical definition of authorization state ◮ A definition of the authorization policy

Introduction A model for Unix What do we learn from this? Concluding remarks

Introduction A model for Unix What do we learn from this? Concluding remarks

Introduction A model for Unix What do we learn from this? Concluding remarks

Basic concepts

We assume the existence of

◮ A set of users U ◮ A set of (protected) objects O ◮ A set of generic actions A ◮ A set of principals P

We define two functions

◮ π1 : U × O → P ◮ π2 : P × O → 2A

Introduction A model for Unix What do we learn from this? Concluding remarks

Basic concepts

We assume the existence of

◮ A set of users U ◮ A set of (protected) objects O ◮ A set of generic actions A = {r, w, x} ◮ A set of principals P = {owner, group, world}

We define two functions

◮ π1 : U × O → P ◮ π2 : P × O → 2A

Introduction A model for Unix What do we learn from this? Concluding remarks

Basic concepts

We assume the existence of

◮ A set of users U ◮ A set of (protected) objects O ◮ A set of generic actions A = {r, w, x} ◮ A set of principals P = {owner, group, world}

We define two functions

◮ π1 : U × O → P ◮ π2 : P × O → 2A

A request (u, o, a) is allowed if and only if a ∈ π2(π1(u, o), o)

Introduction A model for Unix What do we learn from this? Concluding remarks

The function π1

We define two further sets of entities

◮ A set of user identifiers SID ◮ A set of group identifiers GID

We define functions α : U ∪ O → SID, β : U → 2GID, γ : O → GID π1(u, o) =       

• wner

if α(u) = α(o) group if γ(o) ∈ β(u) world

• therwise

π1 defines a policy which determines the principal for which a given combination of user and object is authorized

Introduction A model for Unix What do we learn from this? Concluding remarks

Policy and state

State is encapsulated in α, β and γ and in π2

◮ π1 is actually a policy that determines authorized

principals given state information

◮ The standard protection matrix policy determines

authorized requests (is the request encoded in the matrix

• r not?)

Introduction A model for Unix What do we learn from this? Concluding remarks

Introduction A model for Unix What do we learn from this? Concluding remarks

Introduction A model for Unix What do we learn from this? Concluding remarks

Authorization-related attributes

Users are associated with authorization-related attributes (ARAs)

◮ SIDs, GIDs in Unix ◮ ARAs are bound to users by trusted entities that provide

authentication services Authorization state is not necessarily expressed in terms of ARAs

◮ A principal is “the entity in a computer system to which

authorizations are granted” [Saltzer and Schroeder, 1975]

◮ owner, group, world in Unix ◮ In role-based access control, roles are both ARAs and

principals

Introduction A model for Unix What do we learn from this? Concluding remarks

ARAs, principals and decisions

Given a request, there are three questions that need to be answered

◮ Which ARAs are associated with the requesting user? ◮ Which principals are associated with that set of ARAs? ◮ Are those principals authorized to access the requested

• bject in the manner desired?

XACML only addresses the third of these questions

Introduction A model for Unix What do we learn from this? Concluding remarks

Model instantiation

The basic Unix model (rather than implementation) does not have to specify P or A

◮ The set of principals could be defined as part of the

authorization state, rather than of policy

◮ RBAC allows for arbitrary principals to be defined as part

• f state

The Unix model could have defined π1 differently

◮ An object could have been associated with multiple GIDs

γ′ : O → 2GID

◮ The set of principals could have been extended to account

for situations where ∅ ⊂ β(u) ∩ γ′(o) ⊂ γ′(o)

Introduction A model for Unix What do we learn from this? Concluding remarks

Model instantiation

The Unix model does not have to specify π1

◮ The mapping of ARAs to principals could (for example)

have been determined by the relative locations (physical or logical) of user and object The Unix model does not associate a user with a principal until request evaluation

◮ This provides a mechanism that is well suited to

supporting context-sensitive authorization mechanisms

◮ Different choices of π1 (and P) might yield interesting and

useful alternative access control mechanisms

Introduction A model for Unix What do we learn from this? Concluding remarks

Designing an authorization service

(1) Define the PRA-request authorization model by which principals are associated with authorized requests (2) Define the ARA-PRA authorization model by which ARAs are associated with principals (3) Define the functions that will implement the PRA-request model and ARA-PRA model (4) Define the actual authorization state that will be used to implement the logical authorization state (5) Define the mechanisms by which authentic user-ARA bindings will be acquired

Introduction A model for Unix What do we learn from this? Concluding remarks

Introduction A model for Unix What do we learn from this? Concluding remarks

Introduction A model for Unix What do we learn from this? Concluding remarks

What about current research?

RBAC

◮ Simpler than Unix in some ways (no distinction between

principals and ARAs)

◮ More complex in others (arbitrarily complex set of

principals)

◮ Not clear that any implementation will achieve (some of)

its objectives (simplify per-subject auditing)

◮ Could have taken some useful lessons from Unix

(independence of PRA-request and ARA-PRA authorization models; context-dependent policies)

Introduction A model for Unix What do we learn from this? Concluding remarks

What about current research?

XACML

◮ Confusion of state and policy ◮ Single authorization evaluation function for all

combinations of state and policy

◮ Makes it difficult to evaluate, author and maintain

“policies”

◮ Makes it difficult to enforce “stateful” policies

Introduction A model for Unix What do we learn from this? Concluding remarks

What about current research?

XACML

◮ Confusion of state and policy ◮ Single authorization evaluation function for all

combinations of state and policy

◮ Makes it difficult to evaluate, author and maintain

“policies”

◮ Makes it difficult to enforce “stateful” policies

Lots more detail in the proceedings. . .

Introduction A model for Unix What do we learn from this? Concluding remarks

Future research

◮ Develop an authorization metamodel ◮ Develop authorization models as instantiations of the

metamodel

◮ Treatment of authorization services as composable

components (authorization evaluation functions)

◮ Each AEF has a signature (exposed interface) ◮ Complex AEFs are constructed by coordinating the

responses of simpler AEFs (using standard programming constructs such as selection and iteration)

◮ Move towards “authorization as a service”

Introduction A model for Unix What do we learn from this? Concluding remarks

Questions?