Creating your own custom authorizations and roles
This is my third part of this blog series about AIX Advance RBAC.
This part will show you how you can create RBAC authorizations and roles for your own scripts, executables and config(files).
User defined authorizations
As you can read in the first two parts of this blog series, AIX RBAC has it’s own internal authorizations that are not stored into files but in stored into the ODM and that cannot modified.
So if we like bring our own scripts, executables or files under RBAC control we have to create first the right authorizations for it and store it into the authorizations file.
There are some things to keep in mind before writing / updating the /etc/security/authorizations.
Each authorization has it’s own unique id, and typical IBM uses low numbers for there internal id’s.
When you create you own tree of authorizations, it save to start with id higher then 11000, this to prevent in the future that get a conflict with internal revered id’s form IBM.
It’s also a good idea to create a kind of naming and hierarchical structure for your own authorizations see below example of internal AIX authorizations.
To create such a structure see below an example, I use here files for a local database in part 4 I will cover what you need to store the RBAC database on a LDAP server:
mkauth -R files dfltmsg='team1' id=11001 team1
mkauth -R files dfltmsg='team1 Application1' id=11002 team1.app
mkauth -R files dfltmsg='team1 Applications exec' id=11003 team1.app.exec
mkauth -R files dfltmsg='team1 Application execute cmds' id=11004 team1.app.exec.cmd
Now we created a placeholder to store our own authorizations we have to know what authorizations our script or executable needs.
There are a few ways (two) to achieve this:
The first method:
This describes the tracepriv command. See the command below:
1)First assign the role isso to the user that you like to use for the trace
chuser -R files roles=isso <username>
Note: Be carefull with this, is role is almost the same as being a root user! It’s a good practice to remove this role after you finished your job.
2) Login with the user that can switch now to this role and switch to this role see below:
swrole isso
user Password: <password of user>
3) Set the pv_root privilege for this current shell
setsecattr -p eprivs=PV_ROOT mprivs=PV_ROOT $$
Verify this with:
lssecattr -p $$
<PID_Shell> eprivs=PV_ROOT mprivs=PV_ROOT iprivs= lprivs=PV_ROOT uprivs=
4) Now we have setup the current shell for running the trace.
Run the trace with the following parameters for example to trace your script or executable:
tracepriv -ef -o /tmp/tracepriv.out /path/of/script (I used a ipsec_v4_filt script for this trace)
see man page of tracepriv, I used the -f for a script that uses the fork policy.
5) You now get a text based output file that will list for every command it’s privileges
To get rid of the duplicates you can filter something like:
for n in $(cat tracepriv.out | egrep -vw "Used privileges" | sort -u ); do echo $n ; done | sort -u | grep -vw None
Or: (thanks Mash) better for having everything into one line to create the authorization:
cat tracepriv.out | grep PV | awk '{printf "%s\n%s\n",$1,$2}' | sort | uniq | grep -v ^$ | tr '\n' ',' | awk '{print substr($0,0, length($0)-1)}'
output:
PV_AU_ADD,PV_AU_PROC,PV_DAC_O,PV_DAC_R,PV_DAC_W,PV_DAC_X,PV_FS_CHOWN,PV_NET_CNTL,PV_NET_PORT
6) We now can assign the right privileges to an user defined authorization (tree) we can use something like:
setsecattr -R file -c \
innateprivs=PV_AU_ADD,PV_AU_PROC,PV_DAC_O,PV_DAC_R,PV_DAC_W,PV_DAC_X,PV_FS_CHOWN,PV_NET_CNTL,PV_NET_PORT\
accessauths=team1.app.exec.cmd \
secflags=FSF_EPS \
/example/bin/example.script
7) Verify the just created authorization with:
lssecattr -R files -c /example/bin/example.script
Second method:
This method is mentioned for short running processes and uses the command lssecattr -p <PID>
1) Run a ps -ef or any other command to discover the process-id that you liked to trace.
lssecattr -p <PID>
this command will produce output such as:
2293812 eprivs=PV_AU_,PV_AZ_ADMIN,PV_AZ_READ,PV_AZ_CHECK,PV_DAC_,PV_PROBEVUE_,PV_FS_,PV_PROC_,PV_TCB,PV_TP,PV_TP_SET,PV_KER_,PV_DEV_CONFIG,PV_DEV_QUERY,PV_DEV_LOAD,PV_NET_,PV_MIC,PV_LAB_,PV_MAC_,PV_SEC_TRACE,PV_DOM_ mprivs=PV_AU_,PV_AZ_ADMIN,PV_AZ_READ,PV_AZ_CHECK,PV_DAC_,PV_PROBEVUE_,PV_FS_,PV_PROC_,PV_TCB,PV_TP,PV_TP_SET,PV_KER_,PV_DEV_CONFIG,PV_DEV_QUERY,PV_DEV_LOAD,PV_NET_,PV_MIC,PV_LAB_,PV_MAC_,PV_SEC_TRACE,PV_DOM_ iprivs= lprivs=PV_ROOT uprivs=PV_DAC_O,PV_PROC_PRIV,PV_PROC_TIMER,PV_KER_ACCT,PV_NET_CNTL,PV_NET_PORT
Be aware to capture everything, if the script or program have one or more branches you have to test several time to make your capture complete, but this is also the case in the first method mentioned.
2) Filter again the duplicates see step 5 first method, and followed by step 6 and 7.
Assign the user defined authorization(s) to a role
Now we have created the custom authorization(s) and added the right privileges to our script, or executables we can assign a custom role for it.
This last step is rather simple:
Again also for custom roles always choose a role-id that is high enough to avoid conflicts with the default internal roles
We choose role id’s that starts form 20000.
Step 1:
mkrole -R files \
authorizations=aix.security.network.filt,exec.cmd, team1.app.exec.cmd \
id=20012 \
dfltmsg="example test role command" \
testrole
Step 2:
Do not forget to run the setkst command sets the entries in the kernel security tables (KST).
Step 3:
Now assign the new role testrole to an existing user on your lpar
chuser -R files roles=testrole <user_name>
Step 4:
Loging as the speficic user and switch to the role
swrole user_name ß authenticate with password
do a rolelist -e to check the right role
and a rolerpt -a to check the commands you can run now.
After following those steps, you should be able to create your own collection(s) of scripts executables.
The big benefit is that you do not have to switch to a root account for those RBAC roles, just use the swrole command.
Also for custom roles and authorizations you can assign those role as default role.
Big difference between default authorizations and role compared with custom ones is that you now can narrow your security to a single script/executable or a group of scripts/executables.
Remember that with default AIX authorizations you get often to much access to complete sets of commands.
So far this third part3 of this blog series.
Please let me know if this blog was usefully, if so I will created part4.
That part will explain how to store RBAC default and custom database on an LDAP server.
Thanks to: Ahmed Mashhour for reviewing this part of the blog series!
Please feel free to give me feed back on this subject, I like discussions about those subjects 😊