Docstoc

Role-Based Access Control

Document Sample
Role-Based Access Control Powered By Docstoc
					Role-Based Access Control
                        Overview
 Access control concepts
   » Matrix, ACLs, Capabilities
 Traditional policy models
   » DAC, MAC
 Role-Based Access Control
   » Core RBAC
   » Hierarchical RBAC
   » Constrained RBAC


                                   2
       Access control: introduction
 Security = prevention and detection of unauthorized
  actions on information
 Two important cases:
    » An attacker has access to the raw bits representing the
      information
      => need for cryptographic techniques
    » There is a software layer between the attacker and the
      information
      => access control techniques


                                                                3
         Access control: introduction
 Access control techniques are ways to build this
  software layer such that it allows for simple, flexible
  and efficient implementation of a security policy
 Access control techniques are used in:
    »   Operating systems
    »   Databases
    »   Web servers
    »   Execution platforms for mobile code
    »   …

                                                            4
       Access control: introduction
 Different access control models exist to accommodate
  different policies
 Model should be simple, expressive, intuitive,
  manageable, implementable,…




                                                         5
                  Terminology
 Subjects: users or programs (processes) executing on
  behalf of users
 Objects: anything on which a subject can perform
  operations (mediated by rights)
 Rights: ways to access objects




                                                         6
              Access control matrix
 The rights in a cell specify the accesses of the subject (row) to
  the object (column)

 Example:
   Subject/     File_1           File_2     File_3 Process_1
  object
   Chris        Read, Write      -       Write          -
  Janet          -               Execute -           Suspend
  Barbara        -               Read    Read         -
  Frank         Read               -       -           -

 The access control matrix is typically a conceptual vehicle not an
  implementation structure
                                                                      7
    Access control lists (ACL)

     File_1                    File_2
     Chris:r                   Janet:x
     Chris:w                   Barbara:r
     Frank:r



each column of the access matrix is stored with the
       object corresponding to that column

                                                      8
           Capability lists


       Chris File_1/r, File_1/w, File_3/w

       Janet File_2/x, Process_1/s



each row of the access matrix is stored with the
       subject corresponding to that row

                                                   9
             ACL vs Capabilities
ACCESS REVIEW
  • ACL's provide for superior access review on a per-
    object basis
  • Capabilities provide for superior access review on a
    per-subject basis
REVOCATION
  • ACL's provide for superior revocation facilities on a
    per-object basis
  • Capabilities provide for superior revocation facilities
    on a per-subject basis
                                                              10
             ACL vs Capabilities
 The per-object basis usually wins out so most Operating
  Systems protect files by means of ACL's
 Many Operating Systems use an abbreviated form of
  ACL's with just three entries
   » owner
   » group
   » other

                                                       11
       Discretionary versus Mandatory

 Discretionary access controls (DAC) allow access
  rights to be propagated from one subject to another
   Possession of an access right by a subject is sufficient
   to allow access to the object
 Mandatory access controls (MAC) restrict the access
  of subjects to objects on the basis of security labels



                                                              12
         Inherent weakness of DAC

 Unrestricted DAC allows information to be copied from
  an object which can be read to any other object which
  can be written by a subject
 Suppose our users are trusted not to do this
  deliberately. It is still possible for Trojan Horses to copy
  information from one object to another.




                                                            13
                 Trojan horses
 A Trojan Horse is rogue software installed, perhaps
  unwittingly, by duly authorized users
 A Trojan Horse does what a user expects it to do, but
  in addition exploits the user's legitimate privileges to
  cause a security breach




                                                         14
          Trojan horse example
                                        ACL
                                        A:r
                               File F
                                        A:w



                                        B:r
                               File G
                                        A:w


Subject B cannot read file F
                                              15
          Trojan horse example
Principal A                                              ACL
              executes
                                                         A:r
                          read        File F
   Program Goodies                                       A:w


        Trojan Horse
                                                         B:r
                                      File G
                         write                           A:w


Subject B can read contents of file F copied to file G     16
              Multi level security

             TS



Lattice of   S
 security
  labels
             C
                        Information   Dominance
                            Flow
             U
                                           17
         Bell-Lapadula model (BLP)
SIMPLE-SECURITY
Subject S can read object O only if
    • label(S) dominates label(O)
    • information can flow from label(O) to label(S)

STAR-PROPERTY
Subject S can write object O only if
    • label(O) dominates label(S)
    • information can flow from label(S) to label(O)
                                                       18
                 STAR property
 Applies to subjects not to users
 Users are trusted (must be trusted) not to disclose
  secret information outside of the computer system
 Subjects are not trusted because they may have Trojan
  Horses embedded in the code they execute
 Star-property prevents overt leakage of information and
  addresses Trojan horse problem



                                                        19
 Role-Based Access Control (RBAC)
 Access depends on function, not identity
 Example:
   » Allison, bookkeeper for Math Dept, has access to financial
     records.
   » She leaves.
   » Betty hired as the new bookkeeper, so she now has access
     to those records
   » The role of “bookkeeper” dictates access, not the identity of
     the individual.


                                                                     20
                         Roles
 Role:
   » many-to-many relation between users and permissions
   » Corresponds to a well-defined job or responsibility
 When a user starts a session, he can activate some or
  all of his roles
 A session has all the permissions associated with the
  activated roles



                                                           21
                 RBAC advantage
• For each job position, let:
     U  Number of individuals in job position
     P  Number of permissions required for job position
         (U  P)  (U  P) RBAC advantage
           U , P  2  (U  P)  (U  P)




                                                           22
                 RBAC (NIST standard)

                  UA               PA
        Users              Roles            Operations      Objects


                                                   Permissions
user_sessions               role_sessions
(one-to-many)              (many-to-many)

                Sessions




                                                                      23
              Core RBAC (relations)
   Users: set of users
   Roles: set of roles
   Operations: set of operations
   Objects: set of objects
   UA ⊆ Users x Roles
   assigned_users: Roles  2Users
     » assigned_users(r) = { u  Users | (u, r) UA}
   PRMS = 2Operations x Objects
   PA ⊆ PRMS x Roles
   assigned_permissions: Roles  2PRMS
     » assigned_permissions(r) = { p PRMS | (p, r) PA}
   subject_user: Subjects  Users
   subject_roles: Subjects  2Roles
     » subject_roles(s) = {r | (subject_user(s), r)  UA)}
                                                             24
                          Axioms
 Rule of role authorization:
  (s  Subjects)(u  Users)(r  Roles)
  r  subject_roles(s)  u  subject_users(s) 
  u  assigned_users(r)
   » A subject can never have an active role that is not authorized
     for its user




                                                                  25
                              Axioms
 Definition:
  access: Subjects x Operations x Objects  BOOLEAN
  access(s, op, o) = 1 if subject s can access object o using
  operation op; 0 otherwise
 Rule of object access authorization:
  (s  Subjects)(op  Operations)(o  Objects)
  access(s, op, o)  (r  Roles)(p  PRMS)
  [r subject_roles(s)  p  assigned_permissions(r)  (op, o) p]
    » A subject s can perform an operation op on object o only if
      there exists a role r that is included in the subject’s active role
      set and there exists a permission that is assigned to r such
      that the permission authorizes operation op on o
                                                                        26
                 Role Hierarchies
 Reflect enterprise structure
   » Partially ordered set of roles (R, 6)
 Used to further reduce the number of user- and
  permission-role assignments
   » If (u, r) 2 UA then u is (implicitly) assigned to all roles
     s6r
   » If (p, r) 2 PA then p is (implicitly) assigned to all roles
     s>r

                                                              27
             A typical role hierarchy
 If Jason is assigned to PL1
  then he can also activate all
  roles less senior than PL1
 If permission p is assigned to
  QE1 then it can also be used
  by any role more senior than
  QE1
 Jason can use p




                                        28
                RBAC with Role Hierarchy
                              RH
                       (role hierarchy)




                  UA                  PA
        Users              Roles             Operations      Objects


                                                    Permissions
user_sessions                role_sessions
(one-to-many)               (many-to-many)

                Sessions

                                                                       29
           RBAC with Role Hierarchy
 authorized_users: Roles 2Users
         authorized_users(r) = {u | r’ ≥ r    (r’, u)  UA)
 authorized_permissions: Roles 2PRMS
       authorized_users(r) = {p | r’ ≥ r  (p, r’)  PA}
 RH ⊆ Roles x Roles is a partial order
    » called the inheritance relation
    » written as ≥.
    (r1 ≥ r2)  authorized_users(r2) ⊆ authorized_users(r1) &
    authorized_permisssions(r1) ⊆ authorized_permisssions(r2)




                                                                30
            Separation of Duty
 No single user possesses all the permissions
  needed to perform a sensitive task
 Prevents accidental or malicious violation of
  business requirements
 Examples
  » A cheque must be raised and authorised by two
    different people
  » A nuclear missile must be armed and launched by
    two different people

                                                  31
    Varieties of Separation of Duty
 Static SoD
  » No user can have the opportunity to access both
    file1 and file2
  » Based on configuration of system
 Dynamic SoD
  » No user can have access to both file1 and file2 at
    the same time
  » Based on current state of system
 Historical SoD
  » No user can have accessed both file1 and file2
  » Based on all previous states of the system

                                                         32
                Constrained RBAC
                              RH
   Static              (role hierarchy)
Separation
  of Duty




                  UA                  PA
        Users              Roles                 Operations      Objects


                                                        Permissions
user_sessions
(one-to-many)                              Dynamic
                                          Separation
                                            of Duty
                Sessions
                                                                      33
    Constrained RBAC: Static SoD
 SSD ⊆ 2Roles x N is a collection of pairs (rs, n)
   » rs: role set
   » n: n ≥ 2 is a natural number
 For each (rs, n) in SSD no user is authorized for
  n or more roles in rs




                                                      34
       SoD with Role Hierarchies
 Two roles can be mutually exclusive only if
  neither one inherits the other
 If two roles are mutually exclusive, no role
  can inherit from both
 If two roles are mutually exclusive, there can
  be no “root” or “super user”.




                                                   35
  Constrained RBAC: Dynamic SoD
 DSD ⊆ 2Roles x N is a collection of pairs (rs, n)
   » rs: role set
   » n: n ≥ 2 is a natural number
 For each (rs, n) in SSD no user is allowed to
  activate n or more roles in rs in one session




                                                      36

				
DOCUMENT INFO
Shared By:
Stats:
views:17
posted:6/11/2012
language:English
pages:36