What is RBAC?
It stand for Role Based Access Control.There is major differences between RBAC in AIX 5.3 and older AND RBAC in AIX 6.1/7.1. No value in discussing older RBAC. Will explain for "enhanced RBAC" instead.
Three primary rules are defined for RBAC:
- Role assignment: A subject can exercise a permission only if the subject has selected or been assigned a role.
- Role authorization: A subject's active role must be authorized for the subject.
With rule 1 above, this rule ensures that users can take on only roles for which they are authorized. - Permission authorization: A subject can exercise a permission only
if the permission is authorized for the subject's active role.
With rules 1 and 2, this rule ensures that users can exercise only permissions for which they are authorized.
The traditional DAC
Traditional access control, as we call it DAC (discretional access control) has been used for ages and taken for granted. The familiar string r-x------ is fundamental for all sys admin. DAC provides SUID, GUID, etc but the control scope deals with All, GROUP or OWNER access.AIX RBAC
RBAC provides precise access control such that the target role can only be assumed by a particular user. The range of commands the role can access could be a subset of all the commands that a root or any other account actually have.Difference from SUDO
SUDO is another means to control the access to privilege commands. However, it can be tedious to configure each and every commands that you want to allow an account to access.
Difference from Solaris RBAC
In essence, both Solaris RBAC and AIX RBAC are similar. The main difference is the way to implement it.In Solaris, we use mainly the following files to setup RBAC.
root:/ #ls -l /etc/user_attr /etc/security/exec_attr /etc/security/prof_attr /etc/security/auth_attr -rw-r--r-- 1 root sys 11855 Mar 28 2012 /etc/security/auth_attr -rw-r--r-- 1 root sys 20934 Aug 15 11:40 /etc/security/exec_attr -rw-r--r-- 1 root sys 8433 Aug 15 11:42 /etc/security/prof_attr -rw-r--r-- 1 root sys 1292 Aug 30 12:01 /etc/user_attr
Authorisation file for Solaris.
root:/ #tail -3 /etc/security/auth_attr
solaris.system.:::Machine Administration::help=SysHeader.html
solaris.system.date:::Set Date & Time::help=SysDate.html
solaris.system.shutdown:::Shutdown the System::help=SysShutdown.html
In AIX, this authorisation list is kept in a DB. You can create custom ones, especially for those not already in the DB. AIX don't provide the help HTML file. In reality, do we use them?
server:/: lsauth ALL | tail -3 wpar.mobility.appli id=10014 wpar.mobility.appli.other id=10016 wpar.mobility.appli.owner id=10015
The Solaris file that manage the effective privilege level to execute the command
root:/ #tail -3 /etc/security/exec_attr Zone Management:solaris:cmd:::/usr/sbin/zoneadm:uid=0 Zone Management:solaris:cmd:::/usr/sbin/zonecfg:uid=0 DisasterRecovery Admin:suser:cmd:::/opt/sysadmin/Portnet_DR_Scripts/*:uid=root
Next, not much meaning in this profile file but only to maintain the profile and description of the role
root:/: #tail -5 /etc/security/prof_attr
ZFS Storage Management:::Create and Manage ZFS Storage Pools:help=RtZFSStorageMngmnt.html
Zone Management:::Zones Virtual Application Environment Administration:help=RtZoneMngmnt.html
dtwm:::Do not assign to users. Actions and commands required for the window manager (dtwm).:help=Rtdtwm.html
shutdown:::Do not assign to users. Contains actions requiring shutdown authorization.:auths=solaris.system.shutdown;help=Rtshutdown.html
DisasterRecovery Admin:::For running DisasterRecovery scripts:
In AIX, here it is though we can set much more information, like password control, access to smitty and all that.
server:/: lsrole -f appadmin
appadmin:
authorizations=aix.system.cluster
rolelist=
groups=admingrp
visibility=1
screens=*
dfltmsg=role to manage Application resources
msgcat=
auth_mode=NONE
id=11
In Solaris, the file that assign who can assume the role.
root:/ #tail -3 /etc/user_attr me::::type=normal;profiles=DNS Admin you::::type=normal;profiles=DNS Admin her::::type=normal;profiles=DNS Admin
AIX keep this information in the ODM too.
server:/: lsuser -f meuser | grep role
default_roles=
roles=appadmin
How to setup
Say for instance, powerHA can only be accessed by root. but to allow menu control of cluster resources, we need to have a means to start/stop/restart/suspend/resume/failover the resources without using root. It is a bad security idea to allow menu to manage the cluster resources via root account.Hence, we authorise, say meuser to access powerHA administrative commands by giving it ibm.hacmp.admin authorisation. How do we do that?
Check that Enhanced RBAC is enabled.
# lsattr -El sys0 -a enhanced_RBAC
enhanced_RBAC true Enhanced RBAC Mode True
Let's create the authorisations.
/:> mkauth dfltmsg='IBM custom' ibm /:> mkauth dfltmsg='IBM custom hacmp' ibm.hacmp /:> mkauth dfltmsg='IBM custom hacmp admin' ibm.hacmp.admin
Then check out what privileges that the commands that you are using requires.
# tracepriv -ef /usr/es/sbin/cluster/utilities/clRGinfo
-----------------------------------------------------------------------------
Group Name State Node
-----------------------------------------------------------------------------
apps_rg ONLINE servera
OFFLINE serverb
9568366: Used privileges for /usr/es/sbin/cluster/utilities/clRGinfo:
PV_AU_ADMIN PV_NET_CNTL
PV_NET_PORT
# tracepriv -ef /usr/es/sbin/cluster/events/utils/cl_RMupdate
...
...
...
 | if you need to use your own shell script, you may need to add it into the privileged command database. Allow EUID to be equal to the owner of that script. |
Now we add the commands into the privileged command database.
/:> setsecattr -c innateprivs=PV_AU_ADMIN,PV_NET_PORT,PV_NET_CNTL accessauths=ibm.hacmp.admin /usr/es/sbin/cluster/utilities/clRGinfo
/:> setsecattr -c innateprivs=PV_AU_ADMIN,PV_KER_ACCT,PV_PROC_PRIV accessauths=ibm.hacmp.admin euid=0 /usr/es/sbin/cluster/events/utils/cl_RMupdate
/:> setsecattr -c innateprivs=PV_AU_ADMIN,PV_KER_ACCT,PV_PROC_PRIV accessauths=ibm.hacmp.admin euid=0 /admin.sh /:> setsecattr -c innateprivs=PV_AU_ADMIN accessauths=ibm.hacmp.admin euid=0 /dlpar.sh
You can verify by using lssecattr.
/:> lssecattr -F -c /dlpar.sh
/dlpar.sh:
euid=0
accessauths=ibm.hacmp.admin
innateprivs=PV_AU_ADMIN
Now, we create a role with the above authorisations.
# mkrole authorizations=ibm.hacmp.admin dfltmsg="Custom role to do admin with hacmp" appadmin
| if its for automation, you may want to remove password access to the role by the following command.
chrole auth_mode=NONE appadmin |
Next, allow meuser to be able to assume the role
chuser roles=appadmin meuser
Before you try it out, you need to update the kernel for all these to take effect. As AIX kernel is RBAC aware for all the IBM system commands, without updating the kernel, any changes will not take effect.
setket
Try it out
swrole
If you are not allow to assume the role you will receive the following error. In this example, thatuser should not assume appadmin role.
server:/HAapps: su - thatuser
-bash-3.2$ swrole appadmin
swrole: 1420-052 appadmin is not a valid role for thatuser.
It is authorised to assume meuser role instead.
server:/HAapps: su - meuser -bash-3.2$ swrole appadmin bash-3.2$ /usr/es/sbin/cluster/events/utils/cl_RMupdate suspend_appmon apps apps_rg Suspend HA Monitoring for apps. 2012-10-22T15:58:03.289727 2012-10-22T15:58:03.309369 Oct 22 2012 15:58:03 cl_RMupdate: Completed request to suspend monitor(s) for application apps. Oct 22 2012 15:58:03 cl_RMupdate: The following monitor(s) are in use for application apps: apps_svr apps_dmReference: http://aixhelp.blogspot.sg/2010/12/aix6-rbac.html
No comments:
Post a Comment