General Access Control Model for DAC Also includes a set of rules to modify access control matrix Owner access right Control access right The concept of a copy flag (*) Access control system commands
General Access Control Model for DAC: Example S 1 may place read or read* in any matrix entry in the F 1 column (Rule 1) S 1 can grant and delete to S 2 access rights that S 1 already has (Rule 2, 3) S 1 can destroy S 2 and S 3 (delete the whole rows for them) (Rule8)
UNIX File Access Control UNIX files are administered using inodes (index nodes) Inode control structures t with key information needed dfor a file Each file is controlled by one inode File attributes, permissions and control information are stored in the inode On the disk there is an inode table, or inode list, that contains the inodes of all the files in the file system When a file is opened, its inode is brought into main memory and stored in a memory-resident inode table Directories are structured in a hierarchical tree May contain files and/or other directories i Simply a file that contains file names and pointers to associated inodes
Traditional UNIX File Access Control Owner ID, group ID, protections bits are part of the file s inode Each user Assigned a unique user identification number (user ID) Also a member of a primary group, possibly a number of other groups (each identified with group ID) File Owned by a particular user and marked with that user s ID Belongs to a specific group, either creator s primary group or the group of its parent directory 12 protection bits are associated with each file Nine bits specify read, write, execute permission for the owner, other group members, and all other users Three bits define set user ID (SetUID), set group ID (SetGID), and sticky bit
Traditional UNIX File Access Control Protection mode: 640
Traditional UNIX File Access Control SetUID and SetGID If these are set on an executable file, system temporarily allocates rights of the file owner / group to those of the user executing the file This change is only effective while the program is being executed Enables privileged programs to access files / resources not generally accessible Sticky bit When applied to a directory, it specifies that only the owner of any file in the directory can rename, move, or delete that file Useful for managing files in shared directories Superuser Particular user ID that has system-wide access
Access Control Lists (ACLs) in UNIX Modern UNIX systems support ACLs FreeBSD, OpenBSD, Linux, Solaris FreeBSD Setfacl command assigns a list of UNIX user IDs and groups to a file Any number of users and groups can be associated with a file, each with three protection bits (read, write, execute) A file need not have an ACL, but protected solely by the traditional UNIX file access mechanism FreeBSD files include an additional protection bit that indicates whether the file has an extended ACL
Access Control Lists (ACLs) in UNIX FreeBSD strategy The owner class and other class entries Have the same meaning as in the minimal ACL case The group class entry Permissions represent the maximum permissions assigned to named users or named groups, other than the owning user Additional named users and named groups may be associated with the file Named user
Access Control Lists (ACLs) in UNIX When a process requests access to a file system object, two steps are performed: Step 1 Selects the ACL entry that most closely matches the requesting process by looking at in the following order: Owner, named users, owning / named groups, others Step 2 Checks if the matching entry contains sufficient permissions If more than one group entries match and contain the requested permissions, any entry can be picked; if not, access will be denied (the result is the same no matter which entry is picked)
Role-Based Access Control (RBAC) Assign access rights to roles instead of individual users E.g., job function within an organization Each role will have specific access rights to one or more resources The relationship of users to roles is many-to-many and may be dynamic
Access Control Matrix of RBAC Relates individual users to roles A single user may be assigned multiple roles Multiple users may be assigned to a single role Same structure as the DAC access control matrix with roles as subjects
RBAC Reference Model A family of reference model consists of four models RBAC 0 Contains minimum functionality RBAC 1 includes RBAC 0 functionality and adds role hierarchies, which enable one role to inherit permissions from another role RBAC 2 includes RBAC 0 and adds constraints, which restrict the ways in which the components of a RBAC system may be configured RBAC 3 contains functionality of RBAC 0, RBAC 1, RBAC 2 Models Hierarchies Constraints RBAC0 No No RBAC1 Yes No RBAC2 No Yes RBAC3 Yes Yes
RBAC 0 Base Model User: an individual that has access to this system Role: a named job function that controls this system Permission: an approval of a particular mode of access to one or more objects Session: a mapping between a user and the set of roles (oneto-many relationship) Solid line: relationship or mapping Single arrowhead: one Double arrowhead: many
RBAC 1 Role Hierarchies Reflect the hierarchical structure of roles Use the concept of inheritance to enable eone role to implicitly include access s rights associated with a subordinate role Subordinate roles are lower in the diagram
RBAC 2 Constraints Adapt RBAC to the specifics of security policies Constraint a defined relationship among roles or a condition Constraint types: Mutually exclusive role (non-overlapping permission) A user can be assigned to only one role in the set Any access right can be granted to only one role in the set Cardinality (setting a maximum number with respect to roles) Set a maximum number of users that can be assigned to a given role Set a maximum number of roles that can be granted a particular permission Prerequisite role Dictates a user can only be assigned to a particular role if it is already assigned to some other specified role E.g., a user assigned to a Project Lead role must also be assigned to Production Engineer and Quality Engineer roles
NIST RBAC Model Introduction of the RBAC system and administrative functional specification Defines features or functions required for an RBAC system: 1. Administrative functions Provide capability to create, delete, maintain RBAC elements and relations 2. Supporting system functions Provide functions for session management and for making access control decisions 3. Review functions Provide capability to perform query operations on RBAC elements and relations
NIST RBAC Model Consists of four model components: Core RBAC, hierarchical RBAC, static separation of duty (SSD) relations, dynamic separation of duty (DSD) relations SSD and DSD correspond to the constraints component
NIST RBAC Model Core RBAC Same as RBAC 0, but elaborates on the concept of permission by introducing operations and objects Object A system resource subject to access control (e.g., file, printer, DB records, etc) Operation An executable image of a program, which upon invocation executes some function for the user Permission An approval to perform an operation on one or more RBAC protected objects
NIST RBAC Model Core RBAC Administrative functions Add and delete users from the set of users Add and delete roles from the set of roles Create and delete instances of user-torole assignment Create and delete instances of permission-to-role assignment Supporting system functions Create a user session with a default set of active roles Add an active role to a session Delete a role from a session Check if the session subject has permission to perform a request operation on an object Review functions Enable an administrator to view but not modify all the elements of the model and their relations
NIST RBAC Model Hierarchical RBAC Includes the concept of inheritance of RBAC1 Two types of role hierarchies General role hierarchies Allow an arbitrary partial ordering of the role hierarchy Support multiple inheritance A role may inherit permissions from multiple subordinate roles More than one role can inherit from the same subordinate role Limited role hierarchies Impose restrictions resulting in a simpler tree structure Limitation is that a role may have one or more immediate ascendants but is restricted to a single immediate descendant (role r1 is said to be a descendant of r2 if r1 inherits all of the permissions from r2 and all users assigned to r1 are also assigned to r2)
NIST RBAC Model SSD Relations Enables the definition of a set of mutually exclusive roles If a user is assigned to one role in the set, the user may not be assigned to any other role in the set Can place a cardinality constraint on a set of roles Defined as a pair (role set, n) where no user is assigned to n or more roles from the role set Includes administrative functions for creating and deleting role sets, and adding and deleting role members Includes review functions for viewing the properties of existing SSD sets
NIST RBAC Model DSD Relations As with SSD, limit the permissions available to a user Places constraints on the roles Constraints as a pair (role set, n), where n is a natural number, with the property that no user session may activate n or more roles from the role set Enables the administrator to specify certain capabilities for a user at different time Includes administrative and review functions for defining and viewing DSD relations
Summary Access control Prevent unauthorized users from gaining access to resources Prevent legitimate users from accessing resources in an unauthorized manner Enable legitimate users to access resources in an authorized manner Discretionary access controls (DAC) Controls access based on identity Mandatory access control (MAC) Controls access based on security labels Role-based access control (RBAC) Controls access based on roles