This blog serie will explain why AIX Enhanced RBAC is a good security tool and the goal is to make you more familiar with this build-in feature of AIX.
A brief history of “IBM Advanced Role Based Access Control” or short AIX RBAC: it was first introduced with AIX 6.1 and together with another AIX security feature called Trusted Execution (TE) (see my former blog series).
One of the goals you can achieve with RBAC is to disable the root user, but that this an option not a necessity!
Without going into much detail, but, RBAC has the goal to divide the many (system) tasks of a root user into several other users each having a different role: see also this nice developer works article: https://developer.ibm.com/articles/au-aix_rbac/
Many AIX / Linux user are familiar with SUDO so therefore I try to first explain the difference between them. In this first part I made (far for complete) a little table between the pros and cons of SUDO and RBAC.
|
SUDO
|
RBAC
|
Remarks
|
|
One config file local or LDAP
|
Several attribute files db’s local or LDAP
|
|
|
Commands always executed with root prems
|
Commands are granted via authorizations for a normal user
|
|
|
Access via users or groups
|
Access via authorization, assigned to roles
|
|
|
User traceability is difficult
|
User does not switch traceability same after role switch
|
Enable io log feature to overcome this with SUDO
|
|
Sudoers stored on LDAP possible but not very common
|
Authorizations, Roles and all other attribute files can be stored local or on LDAP
|
|
|
SUDO depends on DAC Discretionary access controls (DAC) and users
|
RBAC Ignores DAC, and depends on roles assigned to users
|
|
|
Removing or access to a rule requires a new sudoers config
|
Admins use the chuser command for assigning or removing roles
|
|
|
Sudoers is widely accepted in the AIX and Linux community
|
RBAC less easier to configure and therefore less admins use it.
|
|
SUDO Usage pros and cons
I try to explain first without judgment if you should use SUDO or not on AIX?
What are the pros and cons:
Pros:
- SUDO usages is widely accepted in the Linux Community, and therefore many sysadmins know how to configure it and use it, which is in my opinion the biggest pro.
- SUDO: is easy to use and can be configured to give access via users, groups and combinations of several other rules.
- Config files can also maintained via Ansible, to make it more save and less vulnerable for modifications.
There are however a lot of cons or maybe concerns with SUDO usage on AIX.
I will not go deep into this discussion, and try to stay objective if you should implement it or not.
Cons:
- During the execution faze of an sudo task the tasks is executed under the root user, this makes it vulnerable for shell escapes.
- Sudo is a honeypot for hackers, see also the first point, when the sudoers is not proper configured it’s easy to get root access.
- Sudo and sudo_ids is Open source software, and therefore it can be installed via DNF on AIX, but there is no officially support from IBM.
Some good advices for using SUDO:
- If you use local configurations put them into the sudoers.d directory.
- Try to avoid wildcards * in the sudoers
- Try to keep the sudoers read-only or push the configs via Ansible or another mechanism.
- It is a good idea to put the config files under TE (Trusted Execution) make the type volatile but lock the config files
- Never put commands in the sudoers that can cause a root escapes, such as vi, sed etc.
- As Andrey also mentioned NEVER user put something in like: user01 ALL=(ALL) NOPASSWD: ALL
- Enable io log feature. Als Alexander mentioned in the discussion sudoreplay is a good idea.
- Log to a log facility what users did during there sudo access offload to a remote syslog server is also a good idea.
- I most likely forget many good advices here…
And YES Andrey made it now possible to centralize the sudoers also on a IBM LDAP servers
See the nice discussion about this subject and the LOT of work Andrey Klyachkin put into this to get the schema fixed for SDS / (IBM Ldap) !
https://community.ibm.com/community/user/power/discussion/sudoers-ldap-and-aix-user-experience#bm0f4c36e4-f464-4162-9426-0b05f21fb791
See the link below were Andrey gives a complete solution, and a schema for using SUDO stored on a IBM LDAP server:
https://powerdevops.substack.com/p/centralizing-sudoers-configuration
So far my words on sudo, there are many best practices, to read about sudo, but this blog series is intend to make you more familiar whit AIX Advanced RBAC.
Now let’s start with the anatomy of RBAC:
Why is FAST, and why is it a good tool to delegate certain roles to specific users.
And for the impatient users: But how does it work and how can I use it?
The first weird thing with RBAC is that you can immediately forget the DAC structure on files and directory, and even on devices.
It’s fast because RBAC is implemented in the AIX kernel.
So even if it seems you have no right to execute or read something according the rwx rwx rwx bits, you get access, or execute rights if you have the right authorization(s) and privileges on a file.
Those rights (authorizations) are assigned to a role.
And the system administrator can assign a role to a user.
The user can switch to this role with the swrole <role> command, the user is asked to identify himself with a password.
The user can verify that the role is active with rolelist -e this shows the effective role.
While having a role active, the user can get a report what commands he can execute during this role with roleprt -a
From the security pdf:
Switching to a new role session creates a new shell (session) without inheriting roles from the prior session. This is accomplished by creating a new process shell for the role and assigning the new role ID (RID) to the process. Creation of the new session is similar to using the su command except in this case only the role ID of the process is changed and not characteristics such as the UID or GID.
Let dive into more details about the structure of RBAC:
As mentioned in the developer word article it works via the following structure:
I added some pictures and more text to clarify it a bit more
Authorizations are assigned to commands
Authorizations: Mechanism to grant access to commands or certain functionality.
Authorizations two types:
System-Defined
Pre-defined, non-modifiable set shipped with AIX.
“AIX” is top level parent.
To list all system-defined authorizations and their description:
lsauth -f -a description ALL_SYS
Note: these system defined authorizations cannot be found in a local database file.
The other database files can be found in /etc/security.
System defined authorizations are hard coded into the kernel. See example below to get an impression, (a peek into the kernel):
echo "kat -system"|kdb -script
read vscsi_scsi_ptrs OK, ptr = 0x0
(0)> kat -system
Executing kat command
system authorizations
--------------------------------------------
nauths....317
name......aix
flags.....0
aid.......10
parent....(0, 0, 0, 0, 0, 0, 0, 0)
name......aix.device
flags.....0
aid.......500
parent....(10, 0, 0, 0, 0, 0, 0, 0)
name......aix.device.config
flags.....0
aid.......520
parent....(10, 500, 0, 0, 0, 0, 0, 0)
~~ and so a lot more ~~
User-Defined
Defined locally in /etc/security/authorizations.
Cannot have “aix” as top level parent.
To list all user-defined authorizations and their description:
lsauth -R LDAP -f -a description ALL_USR
Authorizations management commands:
lsauth List an authorization
mkauth Create an authorization
chauth Change an authorization.
rmauth Remove an authorization.
Roles are assigned to users.
Roles: A container for authorizations that can be assigned to a user.
Roles:
Defined locally in /etc/security/roles.
Role name may be up to 63 printable characters.
Supports concept of sub-role through rolelist attribute.
Role inherits all authorizations of specified sub-roles.
Role management commands:
mkrole Create roles.
chrole Modify roles.
lsrole List roles.
rmrole Remove roles.
With AIX there are default already predefined roles:
ISSO the highest and quite similar to the root user description. Establishing and maintaining security policy settings, SO work station admin, tasks like system shutdown, backup’s, restores, logging, tracing, etc.
SA User admin software installation en device allocation, but not able to set passwords.
To list all default roles you can use:
lsrole -R files -a dfltmsg ALL
Privileges are associated with specific processes.
Explicit privileges are assigned to commands required for execution and their execution is governed by authorizations.
Privileges: Process attribute that allows a process to bypass a security restriction.
Governs the authorizations required to execute a command and the privileges that are assigned if authorization check succeeds.
Defined locally in /etc/security/privcmds
Key command attributes:
accessauths Authorizations allowed to execute the command.
Support for special authorizations (ALLOW_OWNER, ALLOW_GROUP, ALLOW_ALL)
innateprivs Privileges assigned to process if accessauths is met.
authprivs Additional privileges granted if additional authorization met.
inheritprivs Privileges to assign into process IPS = Inheritable Privilege Set
Privileged Command Management Commands
setsecattr -c Add and modify privileged command definitions.
lssecattr -c List privileged command definitions.
rmsecattr -c Remove privileged command definitions
To list all the default privileges use the following command:
# lspriv -v
PV_ROOT Allows a process to pass any non-SU privilege check.
PV_AU_ Equivalent to all Auditing privileges (PV_AU_*) combined.
PV_AU_ADD Allows a process to record/add an audit record.
PV_AU_ADMIN Allows a process to configure and query the audit system.
PV_AU_READ Allows a process to read a file marked as an audit file.
PV_AU_WRITE Allows a process to write or delete a file marked as an audit file, or to mark a file as an audit file.
PV_AU_PROC Allows a process to get or set an audit state of a process.
PV_AZ_ADMIN Allows a process to modify the kernel security tables.
PV_AZ_READ Allows a process to retrieve the kernel security tables.
~~ total number of privileges is 136 on AIX 7.3 ~~
Some more reading to get more understanding what are privilege sets:
Also in the security manual of AIX 7.3 the made a nice paragraph about this, so if you’re interested in the above picture please read the copied part below, or starting on page 89 of:
https://www.ibm.com/docs/en/ssw_aix_73/pdf/security_pdf.pdf
Limiting Privilege Set (LPS)
Defines the hard limit on privileges for a given process. No privilege escalation in the system can raise
process privileges beyond this value. This means that a process cannot acquire any more privileges
than this value using any of the defined system interfaces. In other words, the process is restricted to
these privileges at any point in time. This also means that the rest of the privilege sets will always be
subsets of LPS. Even though LPS cannot be expanded, every process will have the right to reduce the
LPS. However, once the LPS is reduced, it cannot be expanded back to its original value. The lowering
of the LPS allows a process to restrict the boundaries in regard to associated privileges. For example,
Security a process might reduce the LPS just before running a custom user-provided program. By default, all of
the privileges available on the system are set in the LPS for a process.
Maximum Privilege Set (MPS)
The full set of privileges that the process is authorized to use. The MPS can include any privilege in
the LPS, but cannot exceed the LPS. The MPS can change during the lifetime of a process for many
reasons. The following are some of the reasons:
• When the current process executes another privileged command and then gains related additional
privileges
• If the process has the right privilege, then it can expand the MPS programmatically in a dynamic
manner
Effective Privilege Set (EPS)
The list of privileges which are currently active for the process. The EPS is always a subset of the
process' MPS and is used by the kernel to perform access checks in regard to privileged operations.
The EPS can be manipulated by the process and can equal the MPS, but cannot exceed the
MPS. Dynamic manipulation of the EPS can be performed by the process to enforce least-privilege
principles. For example, user-space code can potentially raise the audit privilege bit in the EPS using
the priv_raise API before making an audit-related system call or kernel call. The privilege can then be
lowered with the priv_lower API when the audit call returns.
Inheritable Privilege Set (IPS)
Privileges which are passed from a parent process to its child processes' MPS and EPS. The IPS can
include any privilege in the LPS, but cannot exceed the LPS. The IPS can be set in a process in the
following ways:
• If the process has the proper privilege, it can expand the IPS programmatically through the setppriv
system call
• When a privileged command is run, the privileges specified in the inheritprivs attribute that is
associated with the command are assigned into the IPS.
Used Privilege Set (UPS)
Denotes the privileges that have been used for access checks during the life of the process. The UPS
can be used to determine the privileges required by the process. When the kernel checks if a process
has a given privilege, it stores a successful check in the UPS for the privilege.
Workload Partition Privilege Set (WPS)
A system WPAR can be restricted to not allow all of the privileged operations that are allowed in a
global WPAR. The privileged operations allowed in a system WPAR can be controlled through the WPS.
The global root can assign a limited set of privileges to a WPAR using WPS. The WPS can be specified
in the /etc/wpar/secattrs configuration file or during the start of a WPAR using the /usr/sbin/
startwpar command. All processes running in a WPAR have their LPS equal to their WPS.
A system administrator can use administrative commands to list and modify the various privilege sets
of a process. The lssecattr command can be used to list the LPS, MPS, EPS, IPS, and UPS. The
setsecattr command can be used to modify the LPS, MPS, EPS, and IPS. The UPS cannot be modified
with the setsecattr command since the UPS is a read-only attribute.
Privileged File Database:
Provides editor access to files based on authorizations.
Intended for files which do not have command interfaces.
Access is provided through /usr/bin/pvi command.
Locally defined in /etc/security/privfiles
Privileged file attributes:
readauths List of authorizations granted read access.
writeauths List of authorizations granted write access.
Privileged File Management Commands
setsecattr -f Add and modify privileged file definitions.
lssecattr -f List privileged file definitions.
rmsecattr -f Remove privileged file definitions.
Privileged Device Database:
Provides device access control through privileges.
Defined locally in /etc/security/privdevs
Privileged device attributes:
readprivs Privilege required to read from device.
writeprivs Privilege required to write to device.
Privileged Device Management Commands
setsecattr -d Add and modify privileged device definitions.
lssecattr -d –List privileged device definitions.
rmsecattr -d Remove privileged device definitions
For now this is part 1 of this blog serie about AIX Advanced RBAC.
This was mainly the theoretical part of RBAC. To get more into detail please read the mentioned security pdf: https://www.ibm.com/docs/en/ssw_aix_73/pdf/security_pdf.pdf
To get a bit more familiar with RBAC my advice is to play a bit with the default roles to see how it works. Please do this on a test system. It is also a good habit that before you start to make a copy of the files in /etc/security for the databases privfiles, authorizations, privdevs, roles and privcmds.
In my next part I will explain more the usage of the default roles and authorizations.
Also if there are enough readers I will create a part that explains how to create custom roles.
Please feel free to give me feed back on this subject.
#IBMChampion