IBM Support

Creation of a Role to Run a Custom Command With Enhanced RBAC

Technote (FAQ)


This technote describes how to create a custom role using Enhanced RBAC to permit users to execute a specific command that is not already associated with a role or authorization.

This would usually be a command that was not already included in AIX, such as a 3rd party software command.


If you wish to create a role to authorize users to run a command, first check to see if the command is already part of the AIX privileged command set, using the lssecattr command, as in:
   # lssecattr -F -c /path/to/command

If the command exists there, it will have an authorization and may belong to a role already. If the command is not listed then proceed to the next steps.

First check to see that Enhanced RBAC is enabled

    # lsattr -El sys0 -a enhanced_RBAC
    enhanced_RBAC true Enhanced RBAC Mode True

If the mode is False, the system is using Legacy RBAC. Change it to True by issuing:
    # chdev -l sys0 -a enhanced_RBAC=true
    sys0 changed

And reboot
    # shutdown -Fr

a. Create a user-defined authorization hierarchy.
    # mkauth dfltmsg='IBM custom' ibm
    # mkauth dfltmsg='IBM custom application'
    # mkauth dfltmsg='IBM custom application execute'
    # mkauth dfltmsg='IBM custom execute myapp'

So we've made a hierarchy to allow us to add any custom application, and in this example execute one of them, called "myapp" installed in the /usr/local/bin directory. This hierarchy could be expanded to include application configuration "" for example.

b. Find out what privileges are necessary to run the command.

If the command you wish to create a role for is not in the /etc/security/privcmdsdatabase already, we must find out what privileges are necessary to run the command. Then we can add it to the privileged command database for RBAC. We can use the tracepriv(5) command for this.

As root or account with PV_ROOT privilege run the command under tracepriv:
    # tracepriv -ef -o /tmp/priv.out /usr/local/bin/myapp

The argument -e traces calls to exec() and -f follows calls to fork()

After the command finishes, the output file will contain something like this:

540688: Used privileges for /usr/sbin/savebase:

409672: Used privileges for /usr/sbin/cfgmgr:

This example is partial output from running the "cfgmgr" command, your output will be different.

c. Add the command to the privileged command database.

We assign the privileges necessary to the command as innate privileges in the "innateprivs" stanza, and use the authorization hierarchy defined in step a.
    # setsecattr -c \
    innateprivs=PV_AU_ADD,PV_AU_PROC,PV_DAC_O,PV_PROC_PRIV,PV_KER_ACCT \ /usr/local/bin/myapp

The "-c" option says that these security attributes are being defined for a command.
The "innateprivs" argument are the privileges found from the tracepriv command
The "accessauths" argument gives the authorization hierarchy needed to run the command
Lastly we list the full path to the command itself.

NOTE: In some cases if the command being added is a shell script you may have to add an authorization to change your effective user id (EUID) to match the owner of the shell script, using the "euid" attribute.
Example: If "myapp" above is a ksh script you may need to run ls -l to determine the owner and set euid to it:
    # ls -l /usr/local/bin/myapp
    -r-xr-x--- 1 root system 5997 Dec 1 2009 /usr/local/bin/myapp
Then the complete line would be:
    # setsecattr -c \ innateprivs=PV_AU_ADD,PV_AU_PROC,PV_DAC_O,PV_PROC_PRIV,PV_KER_ACCT \ \
    euid = 0 \

Now check that it was added to the RBAC privilege database:
    # lssecattr -F -c /usr/local/bin/myapp

So the myapp command has been added to the RBAC privileged command database.

d. Create a role containing the authorization necessary to run the command.
    # mkrole dfltmsg="Custom role to run myapp" exec_myapp

We use the authorization hierarchy created in step a. and create a role called "exec_myapp" The role can be displayed using lsrole:
    # lsrole -f exec_myapp
    dfltmsg=Custom role to run myapp

e. Update the kernel security tables (KST) with the setkst command.

All RBAC security checking is performed in the AIX kernel. If the setkst command is not executed, the changes made to the RBAC security database will not be updated in the AIX kernel.
    # 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.

f. Assign the role to a user.

# chuser roles=exec_myapp bob

# lsuser bob
bob id=205 pgrp=staff groups=staff home=/home/bob shell=/usr/bin/ksh login=true su=true rlogin=true daemon=true admin=false sugroups=ALL admgroups= tpath=nosak ttys=ALL expires=0 auth1=SYSTEM auth2=NONE umask=22 registry=files SYSTEM=compat logintimes= loginretries=0 pwdwarntime=0 account_locked=false minage=0 maxage=0 maxexpired=-1 minalpha=0 minother=0 mindiff=0 maxrepeats=8 minlen=0 histexpire=0 histsize=0 pwdchecks= dictionlist= default_roles= fsize=2097151 cpu=-1 data=262144 stack=65536 core=2097151 rss=65536 nofiles=2000 roles=exec_myapp

g. Now when user "bob" logs in he can see that this role has been assigned to him.

$ lsuser -a roles bob
bob roles=exec_myapp

He can switch to this role during his login session by using:
# swrole exec_myapp
bob's Password:

After activating the role the user may now execute the privileged command that is stored in the exec_myapp role.

Also refer to the IBM Redbook "AIX V6 Advanced Security Features Introduction and Configuration"
for further information.

Document information

More support for: AIX family

Software version: 6.1, 7.1

Operating system(s): AIX

Reference #: T1012115

Modified date: 07 March 2016

Translate this page: