Creation of a Custom Role in Enhanced RBAC
Source
https://www-304.ibm.com/support/docview.wss?uid=isg3T1012115
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
enhanced_RBAC true Enhanced RBAC Mode True
If the mode is False, the system is using Legacy RBAC. Change it to True by issuing:
sys0 changed
And reboot
a. Create a user-defined authorization hierarchy.
# 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:
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:
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.
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.
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:
-r-xr-x--- 1 root system 5997 Dec 1 2009 /usr/local/bin/myapp
Then the complete line would be:
accessauths=ibm.app.exec.myapp \
euid = 0 \
/usr/local/bin/myapp
Now check that it was added to the RBAC privilege database:
/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.
We use the authorization hierarchy created in step a. and create a role called "exec_myapp" The role can be displayed using lsrole:
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.
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.
# 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.
bob roles=exec_myapp
He can switch to this role during his login session by using:
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.