why we should take a second
play

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

Introduction A model for Unix Why We Should Take a Second What do we learn from Look at Access Control in Unix this? Concluding remarks Jason Crampton Information Security Group Royal Holloway, University of London NordSec 2008


  1. Introduction A model for Unix Why We Should Take a Second What do we learn from Look at Access Control in Unix this? Concluding remarks Jason Crampton Information Security Group Royal Holloway, University of London NordSec 2008

  2. Disclaimer Introduction A model for Unix What do we learn from this? This is not really a research talk, more of a thought experiment Concluding ◮ What can we learn about authorization by developing a remarks “formal model” for Unix ◮ What can we say about existing authorization models having done this? ◮ How should we approach authorization in the future?

  3. One-slide overview Introduction A model for Unix What do we learn from this? ◮ What is authorization? Concluding remarks ◮ 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?

  4. What is authorization? Introduction A model for Unix What do we learn from An authorization service is a component of a computerized this? system that controls the interaction between users and Concluding remarks 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

  5. Authorization policy and authorization state Introduction A model for Unix In the research community there seems to be some confusion What do we learn from between authorization policy and authorization state this? ◮ Both are required to decide whether a user request to Concluding remarks 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

  6. The Chinese Wall policy Introduction The policy A model for Unix ◮ Every file has an owner What do we ◮ The set of owners are partitioned into conflict of interest learn from this? classes (CIC) Concluding remarks ◮ 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

  7. An information flow policy Introduction A model for Unix The simple security property (SSP) says that a user u is What do we permitted to read object o if λ ( s ) � λ ( o ) learn from this? ◮ The state is defined by the set of users, objects, the Concluding partially ordered set of security labels ( L , � ) and remarks λ : 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

  8. The protection matrix Introduction A model for Unix The confusion between state and policy arises because of the What do we learn from protection matrix model this? ◮ All authorized access requests are encoded in a matrix Concluding remarks ◮ 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)

  9. Two definitions Introduction A model for Definition Unix An authorization policy is a specification of a decision-making What do we learn from function that takes a request query and authorization state as this? inputs and returns an authorization decision Concluding remarks 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

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

  11. Basic concepts Introduction A model for Unix We assume the existence of What do we ◮ A set of users U learn from this? ◮ A set of (protected) objects O Concluding remarks ◮ A set of generic actions A ◮ A set of principals P We define two functions ◮ π 1 : U × O → P ◮ π 2 : P × O → 2 A

  12. Basic concepts Introduction A model for Unix We assume the existence of What do we ◮ A set of users U learn from this? ◮ A set of (protected) objects O Concluding remarks ◮ 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 → 2 A

  13. Basic concepts Introduction A model for Unix We assume the existence of What do we ◮ A set of users U learn from this? ◮ A set of (protected) objects O Concluding remarks ◮ 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 → 2 A A request ( u , o , a ) is allowed if and only if a ∈ π 2 ( π 1 ( u , o ) , o )

  14. The function π 1 Introduction We define two further sets of entities A model for Unix ◮ A set of user identifiers SID What do we learn from ◮ A set of group identifiers GID this? We define functions α : U ∪ O → SID , β : U → 2 GID , Concluding remarks γ : O → GID  if α ( u ) = α ( o ) owner    π 1 ( u , o ) = if γ ( o ) ∈ β ( u ) group   otherwise  world π 1 defines a policy which determines the principal for which a given combination of user and object is authorized

  15. Policy and state Introduction A model for Unix What do we learn from this? State is encapsulated in α , β and γ and in π 2 Concluding remarks ◮ π 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 or not?)

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

  17. Authorization-related attributes Introduction A model for Users are associated with authorization-related attributes Unix (ARAs) What do we learn from ◮ SIDs, GIDs in Unix this? Concluding ◮ ARAs are bound to users by trusted entities that provide remarks 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

  18. ARAs, principals and decisions Introduction A model for Unix What do we learn from Given a request, there are three questions that need to be this? answered Concluding remarks ◮ 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 object in the manner desired? XACML only addresses the third of these questions

  19. Model instantiation Introduction A model for Unix The basic Unix model (rather than implementation) does not What do we have to specify P or A learn from this? ◮ The set of principals could be defined as part of the Concluding authorization state, rather than of policy remarks ◮ RBAC allows for arbitrary principals to be defined as part of state The Unix model could have defined π 1 differently ◮ An object could have been associated with multiple GIDs γ ′ : O → 2 GID ◮ The set of principals could have been extended to account for situations where ∅ ⊂ β ( u ) ∩ γ ′ ( o ) ⊂ γ ′ ( o )

  20. Model instantiation Introduction A model for Unix The Unix model does not have to specify π 1 What do we learn from ◮ The mapping of ARAs to principals could (for example) this? have been determined by the relative locations (physical or Concluding remarks 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

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend