[sudo-workers] question on "Answer" re: AIX RBAC in sudo FAQ

[Michael Felt]

On 01/05/2017 18:33, Todd C. Miller wrote:
> On Mon, 01 May 2017 13:15:16 +0200, Michael Felt wrote:
>
>> I am curious why PV_DAC_{ROX} are needed - the _UID and _GID seem
>> clear enough.
> This was needed for sudo to be able to access some of its own files
> that are root-owned.
>
>> Also, unsure on why:
>> PV_FS_CHOWN is needed (wouldn't that be handled by "sudo chown"?)
> Sudo itself may use the chown system call to set the owner on certain
> files it creates such as the time stamp files and I/O log files.
>
>> PV_PROV_PRIO (why not "sudo nice"?)
> The sudo plugin API allows the policy plugin to specify the priority
> of the command to be run.  The sudoers plugin does not currently
> implement this.
>
>> And, lastly - why try to be specific - when sudo is still elevating
>> the command requested to 'root'. Instead, the options:
>>                 euid
>>                      Specifies the effective user ID to assume when the comman
>> d is run.
>>                 egid
>>                      Specifies the effective group ID to assume when the comma
>> nd is run.
>>
>> Could be used rather than 'innateprivs'.
> Because sudo can run commands are more than just root.
If I understand correctly - normally, sudo is setup using "chmod u+s"

An RBAC way to do the same is:
setsecattr -c euid=0 accessauths=<an_authorization || ALLOW_KEYWORD 
(e.g., ALLOW_ALL)> sec_flags=EFS /path/to/sudo

Ideally, rather than using the keyword ALLOW_ALL an authorization would 
be made and assigned to a role.

e.g., mkauth sudo; mkauth sudo.users; mkauth sudo.admin; mkauth 
sudo.grp.wheel # the last are extra "incase" more granularity is 
needed/desired
setkst # update kernel security table

Then a role:
mkrole authorizations=sudo dfltmsg="sudoer role" sudoer
setkst

The assign a role to a user
chuser roles=sudoer michael

setsecattr -c euid=0 accessauths=sudo sec_flags=EFS /usr/local/bin/sudo
setkst

This is all from documentation - I'll test it.
>
> All that being said, I don't currently have access to an AIX machine
> where RBAC is configured so I'm unable to test sudo in that
> environment.  Someone had tried to get sudo working in a VIO with
> RBAC but never succeeded.  There is some info about this in
> https://bugzilla.sudo.ws/show_bug.cgi?id=498
However, they way this "should" be done is to start a shell, use 
setsecattr to assign PV_ROOT. And then prefix the call to sudo with 
"tracepriv" command.
Assuming something does not work (as the PV_SU_ privelidges did not 
exist 5 years ago, fyi - use the setsecattr -p command to set both 
PV_ROOT and PV_SU_ROOT
My reading  of the documentation - and some guessing - is that 
PV_SU_EMUL and PV_SU_UID are special to "Trusted AIX" when UID=0 not not 
"super".

And then the output from tracepriv will list all the privileges actually 
used.

I wrote a 'simple' case (for apache): see 
http://www.ibmsystemsmag.com/aix/administrator/security/rbac_applications/

Michael
>   - todd