Technote (FAQ)
 
Question
This technote describes how to create a custom role in Enhanced RBAC to permit users to execute a specific command.
 
Answer
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' ibm.app
# mkauth dfltmsg='IBM custom application execute' ibm.app.exec
# mkauth dfltmsg='IBM custom execute myapp' ibm.app.exec.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 "ibm.app.config" 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:
PV_PROC_PRIV PV_KER_ACCT


409672: Used privileges for /usr/sbin/cfgmgr:
PV_AU_ADD PV_AU_PROC
PV_DAC_O PV_PROC_PRIV
PV_KER_ACCT

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
accessauths=ibm.app.exec.myapp /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.

Now check that it was added to the RBAC privilege database:

# lssecattr -F -c /usr/local/bin/myapp
/usr/local/bin/myapp:
accessauths=ibm.app.exec.myapp
innateprivs=PV_AU_ADD,PV_AU_PROC,PV_DAC_O,PV_PROC_PRIV,PV_KER_ACCT

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 authorizations=ibm.app.exec.myapp 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
exec_myapp:
authorizations=ibm.app.exec.myapp
rolelist=
groups=
visibility=1
screens=*
dfltmsg=Custom role to run myapp
msgcat=
auth_mode=INVOKER
id=11

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"
http://www.redbooks.ibm.com/abstracts/sg247430.html
for further information.