Domain RBAC

Edit online

Role-based access control (RBAC), introduced in AIX® 6.1, provides a mechanism to split the various functions of the super user root into roles, which can be delegated to other users on the system. RBAC provides the facility to delegate duties and improves the security of the system because the auditing and tracking of activities on the system is easier. RBAC provide delegation of responsibility to another user (referred as an authorized user), but it does not provide a mechanism to limit the administrative rights of an authorized user to specific resources of the system. For example, a user that has network administrative rights can manage every network interface on the system. You cannot restrict the authorized user to modify a set of interfaces.

The domain feature for RBAC is used to restrict access to authorized users. The users and resources of the system are labeled by attaching tags called domains, and the specific access rules determine access to resources by the users.

Definitions
The following definitions are related to access rules:
subject: A subject is an entity that requests access to an object. An example of a subject is a process.
object: An object is an entity that holds information of value. Examples of objects are files, devices, and network ports.
domain: A domain is defined as a category to which an entity belongs. When an entity belongs to a domain, access control to the entity is governed by the access rules as follows:
Access rules
  • A subject can access an object when it has all the domains to which the object belongs. This specifies that the list of domains the subject belongs to is a super set of an object's domains. This is the default behavior.
  • A subject can access an object when it has at least one domain of the object. That is, the subject and object have one domain in common. This behaviour depends on the security flags of the object.
  • An object can deny access to certain domains. If an object defines a set of domains called conflict sets and if one of the domains of the subject is part of the conflict set, the object can deny access to the subject.

Domains Database

The domains supported by the system must be stored in a configuration file under /etc/security/domains. The format of a stanza in the file is as shown:
domain-name:
id = <number>
dfltmsg = <Message>
msgcat = <Message catalog>
msgset = <Message set in catalog>
msgnum = <Message id in catalog>
The database can be manipulated using the mkdom and chdom commands. Use the lsdom command to view the database. To delete the entries use the rmdom command.

The entries in the database are not effective until it is downloaded to the kernel by using the setkst command.

A maximum of 1024 domains are supported on the system and the highest possible value of the domain identifier (ID attribute) is 1024.

Domain-Assigned Objects

To assign a domain to an object, it must be defined in the Domain-Assigned Objects database. The domains for all the entities on the system are stored in the configuration file under /etc/security/domobjs. The format of a stanza in the file is as shown, which is an example to assign a domain to an object. 
/dev/hrvg:
domains=HR,IT
conflictsets=payroll
objtype=device
secflags=FSF_DOM_ANY
domains: Specifies the domains that are allowed to access the object. Examples of the domains are IT, HR, and Payroll.
objtype: Indicates the type of object that gets assigned to a domain. The different kind of objtypes are device, file, netint, and netport.
conflict sets: Indicates that if the subject belongs to any domain listed in this attribute in this set, it is not allowed access to the object.
secflags: This flag specifies the special properties of the object. The flags can be set to FSF_DOM_ANY or FSF_DOM_ALL. If the flag is set to FSF_DOM_ANY, a subject can access the object if it contains any one of the domain specified in the domains attribute listing. If the flag is set to FSF_DOM_ALL, all the domains in the listing must be satisfied by the subject to access the object. If no value is specified, the default value of FSF_DOM_ALL is used. The secflag affects only the behavior of the domains attribute of the object.
Domains can be assigned to the files in the file systems. By default, all domains of the object must be a subset of domains of the process to enable the process to access the object.
  1. Devices: All devices (including file systems) can be assigned to a domain. The domain checks are done during management activities, such as configuring the device.
    /dev/hrvg:
domains=HR,IT
conflictsets=payroll
objtype=device
secflags=FSF_DOM_ANY
  2. Network interfaces: When network interfaces (for example: en0) are assigned to the domain, the management activities, such as shutting down the interface will require the interface to undergo domain checks. 
    en0:
domains=NETIF,ADMIN
objtype=netint
flags=FSF_DOM_ALL
  3. Network ports: The TCP and UDP ports can be assigned to the domain. Domain checks are enforced when an application tries to bind to a port. 
    TCP_<port#>:
domains=NETIF,ADMIN
type=netport
flags=FSF_DOM_ALL
  4. Processes: A process inherits domains of the user on whose behalf the process is running. When a user logs in, the user shell process has the domains of the user. When the domains are set, these domains of the process remain through their lifetime. The domains of a process cannot be changed by any user interface or system call. The only process that can set the domains is the login process. The processes do not have the conflict set and secflags attributes.

Current Limitations

The following items are limitations with the current domain RBAC facility:
  • The domain configuration is currently supported on the local system and on lightweight directory access protocol (LDAP) server.
  • RBAC domains are not supported within AIX workload partitions (WPARs).
  • You cannot apply RBAC domains to transient files.

Enhanced RBAC Requirement

The domain RBAC is created on Enhanced RBAC and requires Enhanced RBAC to be enabled on the system to be effective.

Kernel Security Tables

The domains and Domain-Assigned Objects as defined in the domain database and Domain-Object database are effective after they are downloaded to the kernel by using the setkst command. The two tables are referred as Kernel Domain Table (KDOMT) and Kernel Domain Object Table (KDOT).

For additional details on kernel security tables and setkst, see the topic role based access control (RBAC) in AIX Security Guide.

Domain Commands

The following table lists the domain RBAC-related commands that are provided in the AIX operating to manage and use the domain-RBAC framework:
Command Description
mkdom Creates a new domain
lsdom Displays domain attributes
rmdom Removes the domain
chdom Changes the domain attributes
setsecattr Sets the security attributes of a Domain-Object database
lssecattr Displays the security attributes of a Domain-Object database
rmsecattr Removes the definition of a Domain-Object database
setkst Sends the entries in the domain RBAC user-level databases to the Kernel Security Tables

Domain RBAC-related files

The following table lists the RBAC-related files that are provided in the AIX operating system to configure and store the database information:
File Description
/etc/security/domains Domain database
/etc/security/domobjs Domain-Object database

Using Domains

Defining domains: The domains are defined in the Domain database by using the mkdom command. 
mkdom id=24 HR
Assigning domains: The domains can be assigned to entities, such as users, files, devices, network ports, and interfaces. All entities other than users support conflict sets and security flags (secflags).

Users: Users are assigned to domains by using the chuser, and chsec commands.

Syntax:

chuser domains = <comma-separated list of domains> username
Example: 
chuser domains=INET john

During login, the domains assigned to the user are activated. You must login again in case the domains were changed while your session was active, for the new domains to be effective.

Objects: To restrict access to objects through domains, the object must be defined in the Domain-Object database by using the setsecattr command.

Syntax:
setsecattr -o domains=<comma-separated list of allowed domains>
conflictsets=<comma-separated list of restricted domains>
secflags=<FSF_DOM_ALL or FSF_DOM_ANY>
objtype=<file or device or netint or netport>
object-path
Example: 
setsecattr -o domains=INET,WEB conflictsets=DB secflags=FSF_DOM_ANY objtype=netint en0