AIX

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 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.