SELinux & Access Controls - 2

A role is chiefly a semantic construct forming the basis of access control policy. With RBAC, system administrators create roles according to the job functions performed in a company or organization, grant permissions (access authorization) to those roles, and then assign users to the roles on the basis of their specific job responsibilities and qualifications. which means you could you reflect your organisation structure to Roles. For example, an operator role might access all computer resources but not change access permissions; a security-officer role might change permissions but have no access to resources; and an auditor role might access only audit trails.

The standard “ANSI/INCITS 359-2004” consist of two parts:

• Reference Model

• Functional Specification of the model components

The reference models are:

1. Core RBAC defines a minimum collection of RBAC elements, element sets, and relations in order to completely achieve a Role-Based Access Control system. This includes user-role assignment and permission-role assignment relations, considered fundamental in any RBAC system. In addition Core RBAC introduces the concept of role activation as part of a user’s session within a computer system. Core RBAC is required in any RBAC system, but the other components are independent of each other and may be implemented separately.
2. Hierarchical RBAC adds relations for supporting role hierarchies. Hierarchical RBAC goes beyond simple user and permission role assignment by introducing the concept of a role’s set of authorized users and authorized permissions.
3. Static Separation of Duty Relations adds relations among roles with respect to user assignments. Because of the potential for inconsistencies with respect to static separation of duty relations and inheritance relations of a role hierarchy, the SSD relations model component defines relations in both the presence and absence of role hierarchies.
4. The fourth model component, Dynamic Separation of Duty Relations, defines relations with respect to roles activated as part of a user’s session.

RBAC verses MAC & DAC:

Some says it is adjunct of them and some says it replacement of them.

RBAC & Groups:

When we create groups in Microsoft Windows 2000 for example, we could easily add users to these groups. So, we consider the groups as collection of users. Also, as when assign permission we grant it to groups or individual users. But we face a big challenge when we need to specify where exactly certain group have been granted permissions but if we use RBAC it will be extremely easy task. As we mentioned before Role is a collection of users and permissions so determine which user and permission granted specified role become easier task across the enterprise. Also, Role consider as a policy component which regardless the implementation will have the same rule set. But, on the other hand group as implementation specified.

RBAC & Access Control List (ACL):

In ACL the access rights of the object is stored with in the object itself, which made weakness in the access control system and complicate the access management. Suppose you granted access rights to some individual uses and groups, and these access rights stored with the object, and later on you revoked these rights from group. You may find the security assurance here become difficult to achieve especially when your systems getting bigger and bigger because you may left some individual users have access rights.

References:

1. IEEE Computer magazine, February 1996(Vol.29,No.2)pp.38-47
2. NIST - Role Based Access Control
3. Information Security Management Handbook, Chapter 61 by Ian Clark.
4. OASIS eXtensible Access Control Markup Language (XACML) TC