This article provides data in simplified terms for using Domain RBAC to gain granular access on resources and objects. It also gives examples on implementing domain RBAC on resources.

Share:

Uma Chandolu (uchandol@in.ibm.com), AIX security developer and support specialist, IBM

Photo of Uma ChandoluUma M. Chandolu works as a development support specialist on AIX. He has over 6 years of extensive hands-on experience in AIX environments and demonstrated expertise in AIX system administration and other subsystems. He has experience interfacing with customers and handling customer-critical situations. He has been recognized as an IBM developerWorks Contributing Author. You can reach him at uchandol@in.ibm.com.


developerWorks Contributing author
        level

R. Vidya (vidyar@in.ibm.com), AIX senior kernel developer, IBM

Photo of R. VidyaR. Vidya works as technical lead and advisory engineer for the AIX security development team in India. She has a baccalaureate in engineering and a master's in science. She has over 13 years of IT experience and has expertise and exposure to security kernel, filesystems and various other subsystems including application/kernel debuggers, memory allocation functions and more.



20 September 2011

Introduction

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
Illustration of the overview of a 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.

CommandDescription
mkdomCreates 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 -R option.
lsdomLists the domains which exist in domain database. Users can specify a remote module name with -R option.
chdomChanges the existing domain attribute information. chdom also supports changing domain attributes on remote databases by specifying -R option.
rmdomRemoves the domain from the domain database. To remove on a remote database specify -R option.
setsecattrAdds or modifies domain attributes for an object. A new -o option in handles domain objects.
lssecattrList domain attributes for an Object. A new -o option lists domain objects.
rmsecattrThis 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 mkuser and chuser commands.

Domain database

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.

Example 1

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
  1. Create a domain with the mkdom command.
    #mkdom HR
  2. The lsdom command can be used to list the domain.
    # lsdom HR
    HR id=51
  3. 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
  4. 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.
  5. 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
  6. Add the john user to HR domain.
    # chuser domains=HR john 
    # lsuser -a pgrp domains john 
    john pgrp=payroll domains=HR
  7. 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.

Example 2

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
Illustration of 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.

Conclusion

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.

Resources

Learn

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.

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into AIX and Unix on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=AIX and UNIX
ArticleID=758479
ArticleTitle=Introduction to Domain RBAC
publish-date=09202011