[sudo-workers] sudo and AIX RBAC integration - next steps

[Michael Felt]

Dear all,

Last year I experimented with integrating sudo with AIX RBAC. IMHO, both 
RBAC (UI aka management interface) and sudo are authentication 
mechanisms - with their specific grammar. The key difference is the 
amount of privilege granted to an authorized user.

SUDO is (what I call) an "all-or-nothing" approach to privileges. When 
authorized a user "RUNS_AS" another user - getting all privileges that 
account has. When the (default) RUNAS is 'root' a user has, effectively, 
all the privileges of the root aka superuser account.
AIX RBAC, according to the documentation, is an authentication mechanism 
that is based on LPP "Least Privilege Principle" (or PLP. Principle of 
Least Privilege - 
https://en.wikipedia.org/wiki/Principle_of_least_privilege).

In other words, SUDO and AIX RBAC have mechanisms for determining "is 
user authorized" to run a command. With SUDO, when the answer is yes, 
the command is "RUNAS" as a certain UID, and the privileges of the UID 
determine the privileges granted.
With AIX RBAC - when a user is authorized - there is an optional list of 
kernel privileges that can be "raised", as needed, as part of executing 
the command.

Getting back to my experiment - I was able to add some AIX specific code 
- to recognize AIX RBAC roles are active for the current user, and in 
that case assign the "super" privilege PV_ROOT. This worked "as 
expected" even though the binary was neither SUID nor owned by "root" (I 
used bin:bin, but in production I would create a "sudo" user and group 
to own the "sudo config files, etc."

The next step would be to figure out how to integrate the sudoers config 
file syntax.

My first thought was to work from the "RUNAS" concept - except it could 
be a ROLE. The problem here is that ROLES, in AIX RBAC terms, are the 
mechanism for assigning authentication (keys) that unlock privileges. 
The better approach, imho, would be to see an AIX role as equivalent, in 
SUDOERS context, as group membership. The principle: a user is a member 
of a group, and/or a user is a "member of" a role. I feel it fits 
because a rolename is used as basis for being "authorized" just as being 
a member of a group (e.g., wheel) is now.

As a "next step" this could be enough to move forward (i.e., sudo binary 
would still assign PV_ROOT to the program, but the euid would still be 
unchanged from the ruid.

Two questions: with only this addition - would this be acceptable for 
the base code - OR - must we wait for the "final" stage where there is a 
grammar extension (perhaps a separate plugin) to specify the individual 
AIX kernel privileges that need to be activated (and have a configure 
option to specify a default priv such as PV_ROOT when nothing is specified).

My apologies for the brevity (and maybe misspelled words). I am 
interested on your responses; whether it is extremely different in what 
is being (or has been) considered (or done) to integrate "SELINUX RBAC"

Sincerely,
Michael Felt