Managing users and groups and controlling their access is always a critical task in operating systems. AIX provides a facility to delegate administrative roles to non-root users through role-based access control (RBAC) mechanism. With RBAC, users with administrative roles on software and hardware components are able to do administrative tasks on all those components. The limitation with this mechanism is that users will be able to manage all similar entities with one role. Domains are introduced on top of RBAC to eliminate this limitation. Domain RBAC is available from AIX 6.1 Tl06 and AIX 7.1 Tl01 releases onwards.
The scope of this article is to provide an overview of Domain RBAC, components which are introduced through Domain RBAC and Domain RBAC commands usage with an example in a simplified format to give a nutshell usage guide.
Overview of Domain RBAC
In simple terms, "DOMAIN RBAC is a mechanism to restrict the access to unauthorized users on resources" or "DOMAIN RBAC in general provides object isolation for privileged and authorized users with a given role."
With the introduction of RBAC, a feasibility of extending administrator roles and responsibilities to non-root users is provided. Domain RBAC provides fine granular control access over resources for users and requires Enhanced RBAC to be enabled. Domain RBAC does not work in legacy RBAC mode. Domain RBAC is enabled by default on enhanced RBAC mode system.
Domain RBAC introduces some new components and these are as discussed below.
- Domains - Domains can be classified as a "human readable security tags or names which are associated with object and users on the system."
- Objects - An object is an entity which holds information. Objects on a system could be files, file systems, volume groups, devices, and more.
- Subjects - An entity that needs information from an object. Typically processes running on behalf of a user are referred to as subject.
- Property - A property is a rule set that determines whether a subject is granted access to an object.
- Alpha rule - Object's domain set is a subset of subject's domain set
- Star property - It is a special property of an object. Minimum one common domain required between subject and object.
- Conflict set - A conflict set is a domain object attribute that restricts access to a domain based upon the existing domain(s) access that an entity may already have defined.
- Secflags - Secflags is a domain object attribute. It specifies the security flags based on the property of an object. Valid values are:
- FSF_DOM_ANY - It follows star property rule. At least one common domain is required between subject and object. Then only user will be allowed to access object through the subject.
- FSF_DOM_ALL - It follows Alpha rule property of an object. Subject should be holding all object's domain set.
Domain is an additional access control mechanism. Existing access control mechanisms are not bypassed. For example, domain access control mechanisms honors Discretionary Access Controls (DAC) and RBACs. Therefore access to a object by the subject, or running process with domain tags, are granted only if DAC and RBAC are successful in addition to adhering to governing rules mandated by Domain RBAC. Figure 1 below is an illustration of the discussion made above.
Figure 1. Overview of Domain RBAC
Protecting information on a system is always a critical task from unauthorized access. The information can be accessed through software or hardware components on a system. The information is stored in the form of objects like files and directories. The object can be accessed through the subjects.
If a user doesn't have DAC permissions on object and having Domain privilege do not allow the user to access that object through the subject. It follows bottom-to-top approach as specified in the above diagram.
Domain RBAC commands
Domain RBAC introduces four new commands and uses some existing commands to handle domain operations on a system.
|mkdom||Creates a new domain in the domain database. Users can
specify domain attributes with the mkdom command. It also supports creating
domains on LDAP database with the |
|lsdom||Lists the domains which exist in domain database. Users can
specify a remote module name with |
|chdom||Changes the existing domain attribute information. chdom
also supports changing domain attributes on remote databases by
|rmdom||Removes the domain from the domain database. To remove on a remote database
|setsecattr||Adds or modifies domain attributes for an object. A new |
|lssecattr||List domain attributes for an Object. A new |
|rmsecattr||This removes domain object definition from domain database. rmsecattr does not remove the object from the system. It just removes domain definition from domain database.|
Domains are assigned to users. User's domains are evaluated while accessing a domain object. Domains can be assigned to users
during its creation or later with
Domains are defined under the /etc/security/domains file. The information is stored in stanza format under this database.
Domain objects are defined under the /etc/security/domobjs file. The information is stored in stanza format under this database.
The /usr/sbin/setkst command downloads Domain and Domain object information from the /etc/security/domains, and /etc/security/domobjs files into the kernel. Whenever users try to access an object through subject, the kernel verifies the subject domains before granting access to an object. If information is stored in a remote database, it gets downloaded to the kernel based on definition in /etc/nscontrol.conf file.
On a server, a payroll application is configured. This application generates an employee salaries log (esalary.log) file at the end of every month. By default, all users under the payroll group are allowed to access this log file. However, payroll administrator wants to restrict access to this log file.
# ls -l esalary.log -rw-r--r-- 1 payroll 12785 Mar 27 13:49 esalary.log
- Create a domain with the mkdom command.
- The lsdom command can be used to list the domain.
# lsdom HR HR id=51
- Assign the domain HR to the domain object file (esalary.log) using setsecattr command.
# setsecattr -o domains=HR objtype=file /payroll/esalary.log # lssecattr -o /payroll/esalary.log /payroll/esalary.log domains=HR objtype=file
- Load the domain and domain object database into the kernel with the setkst command.
# setkst Successfully updated the Kernel Authorization Table. Successfully updated the Kernel Role Table. Successfully updated the Kernel Command Table. Successfully updated the Kernel Device Table. Successfully updated the Kernel Object Domain Table. Successfully updated the Kernel Domains Table.
- Users john and bob belong to payroll group. By default both the these users currently
are able to access this file.
Now the payroll administrator wants to restrict the access to bob.
# lsgroup payroll payroll id=202 admin=false users=john,bob registry=files
- Add the john user to HR domain.
# chuser domains=HR john # lsuser -a pgrp domains john john pgrp=payroll domains=HR
- Login with as user john and access that file.
# su - john $ cat /payroll/esalary.log Note: user able to access this file
When user bob tries to access this file, he gets following error message:
# su - bob $ cat /payroll/esalary.log cat: 0652-050 Cannot open /payroll/esalary.log.
As previously discussed, domains can be applied to volume groups as well. The following example describes how domains can be assigned to volume groups.
Consider a system configured with three volume groups (VG1,VG2 and VG3). By default, system administrators (root) are able to manage all of the volume groups. Admin privileges can be delegated to normal users in the RBAC model to manage volume groups. With this privilege a normal user can manage all the three volume groups.
However to restrict management of logical volumes by administrators in granular fashion based on the required resources, domains can be assigned to them. By assigning domains to volume groups and administrators, a normal user can be restricted in managing volume groups.
In Figure 2, users Admin1, Admin2 and Admin3 are logical volume administrators and are ideally designated to manage any of the logical volume groups (vg1, vg2 and vg3) in RBAC model. However, with Domain RBAC user admin1 can be assigned with domain identifier blue, admin2 can be assigned with domain identifier red, and admin3 can be assigned with domain identifier green to manage volume groups vg1, vg2, and vg3 whose domains are blue, red, and green respectively.
Figure 2. Managing volume groups with domains
As shown Figure2, the system is configured with three volume groups.
# ls -l /dev/vg1 /dev/vg2 /dev/vg3
crw-rw---- 1 root system 10, 0 May 30 16:41 /dev/vg1 crw-rw---- 1 root system 34, 0 Jun 12 13:28 /dev/vg2 crw-rw---- 1 root system 44, 0 Jun 12 13:28 /dev/vg3
The following role gives privileges for normal user to manage all the volume groups configured on the system:
# mkrole authorizations=aix.lvm.manage.create VGrole # lsrole VGrole VGrole authorizations=aix.lvm.manage.create rolelist= groups= visibility=1 screens=* dfltmsg= msgcat= auth_mode=INVOKER id=11
Assign VGrole role to the users:
chuser roles=VGrole Admin1 chuser roles=VGrole Admin2 chuser roles=VGrole Admin3
With this role, Admin1, Admin2 and Admin3 are able to manage the VG1,VG2 and VG3 volume groups. However, if administrator want to restrict the access to individual volume groups for users Admin1, Admin2 and Admin3, create domains for those volume groups.
By assigning domains to these volume groups, users can be restricted accessing these resources.
mkdom BLUE;mkdom RED;mkdom GREEN
Assign domains to volume groups by using setsecattr command.
setsecattr -o domains=BLUE objtype=device /dev/VG1 setsecattr -o domains=RED objtype=device /dev/VG2 setsecattr -o domains=GREEN objtype=device /dev/VG3
Also users who need access to the corresponding volume groups, assign those domains to users with chuser command.
chuser domains=BLUE Admin1 chuser domains=RED Admin2 chuser domains=Green Admin3
Login with Admin1 user and able to create logical volumes under VG1 volume group.
#mklv -y testlv VG1 12
User Admin1 is restricted to manage volume groups VG2 and VG3. Similarly Admin2 and Admin3 users are restricted in accessing other volume groups.
Domain RBAC LDAP support
The domain database can be configured on an LDAP server, as well. All LDAP clients can download the domain database and can use the same. From AIX 6.1 Tl07 and AIX 7.1 Tl02 releases, domain databases can be configured on LDAP server. All domain and LDAP commands are modified to support it.
Limitations with domains
- Domain RBAC requires Enhanced RBAC mode to be enabled on the system.
- Domain RBAC allows creating 1024 domain object's on the system.
- Domain RBAC allows creating 1024 domain ID on the system.
Role-based access control provides (RBAC) access by normal users with privileged management, whereas DOMAIN RBAC enables user further with privileged management of domains object thereby restricting control on need only resources.
- "AIX Security Documentation", provides manual pages for Domain RBAC
- "AIX 7.1 Difference Guide", provides difference between AIX 6.1 and AIX 7.1
- In the XML area on developerWorks, get the resources you need to advance your XML skills, including DTDs, schemas, and XSLT.
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Attend a free developerWorks Live! briefing to get up-to-speed quickly on IBM products and tools as well as IT industry trends.
- Watch developerWorks on-demand demos ranging from product installation and setup demos for beginners, to advanced functionality for experienced developers.
Get products and technologies
- Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, use a product in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement Service Oriented Architecture efficiently.
- Try out IBM software for free. Download a trial version, log into an online trial, work with a product in a sandbox environment, or access it through the cloud. Choose from over 100 IBM product trials.
- Follow developerWorks on Twitter.
- Participate in developerWorks blogs and get involved in the developerWorks community.
- Get involved in the My developerWorks community.
- Participate in the AIX and UNIX® forums:
Dig deeper into AIX and Unix on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.