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

[Michael Felt]

On 01/05/2017 20:34, Michael Felt wrote:
> On 01/05/2017 20:02, Michael Felt wrote:
>> 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. 
>
> One of my pet-peeves: IBM keeps changing the rules - and I do not know 
> if I have found a bug, or if the rules have been changed drastically. 
> For the moment: setsecattr -p iprivs=PV_ROOT <PID> is not working. The 
> command needs to be something more like this (on AIX 7.1)
>
>
> setsecattr -p 
> eprivs=PV_AU_,PV_AZ_ADMIN,PV_AZ_READ,PV_AZ_CHECK,PV_DAC_,PV_PROBEV
> UE_,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_A
> Z_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=PV_ROOT 4063374
>
>
> Anyway - research time...
The good news is: working as designed. My "bad luck" that I was trying 
to run a program with r-x------ permissions.
-r-x------ 1 root security 82658 Aug 19  2016 /usr/sbin/lsauth

As I could not start it, I could not get my promoted privileges 
activated. "iprivs" are not innate privileges (but inherited (by child 
processes) privileges.

> Michael
>
> ____________________________________________________________
> sudo-workers mailing list <sudo-workers at sudo.ws>
> For list information, options, or to unsubscribe, visit:
> https://www.sudo.ws/mailman/listinfo/sudo-workers