[redhat-lspp] Re: Adminstrative Roles - Take Two

Michael C Thompson thompsmc at us.ibm.com
Thu May 11 14:39:19 UTC 2006


Daniel J Walsh wrote:
> Michael C Thompson wrote:
>> Hey all,
>>
>> I'm preempting the minutes from the call to begin a nice solidified 
>> list of things that constitute the permissions of the administrative 
>> users (and staff) on the system. As this gets developed, I will add it 
>> to the Fedora Wiki [ http://fedoraproject.org/wiki/SELinux ].
>>
>> I would like to focus more on talking about how the policy should 
>> work, and less about how the policy does work.
>>
>> There are 3 administrative roles and 2 user roles:
>> sysadm_r
>> secadm_r
>> auditadm_r
>>
>> staff_r
>> user_r
>>
>> From the notes I took on the call:
>> ----------------------------------
>>
>> auditadm's privilages (for administrative actions) are limited to:
>> auditctl, ausearch and aureport usage
>> manage /etc/audit* files - this includes read and write
>> start/stop auditd
>> view/modify audit log
>>
>> Also, Dan said auditadm should be running @ SystemHigh, I know it 
>> affects the audit.log since that is at SystemHigh, but how much does 
>> this affect usage of the tools?
>>
>>
>> secadm is the manager of SELinux policy, semanage tools, enforcing 
>> on/off, load policy, etc. secadm also has privilages to view audit 
>> logs, but not make modifications to them.
>>
>>
>> sysadm does everything else that is not listed above. w.r.t. to an 
>> overlay on auditadm's privilages, the sysadm role can:
>> start / stop auditd
>> view /etc/audit* only
>>
>> This means sysadm does not have the privilage to modify any 
>> /etc/audit* files, or use any of the audit tools (auditctl, ausearch 
>> or aureport)
>>
>>
>> Information not from the call I believe to be correct:
>> ------------------------------------------------------
>> user_r is not capable of taking any "administrative" actions, and 
>> otherwise normal user activities should work as expected.
>>
>> staff_r is the only "user" role which is capable of transitioning to 
>> the "administrative" roles, but can not do any administrative actions 
>> as the staff_r role.
>>
>> staff_t has the same privilages as user_r, with the additionally 
>> aforementioned transition privilages.
>>
>> secadm_r can load policy, etc. I would expect this is restricted only 
>> to  the secadm_r role.
>>
>> secadm_r can load policy, etc. I would expect this is restricted only 
>> to  the secadm_r role.
>>
>>
>> Questions from arising from this data:
>> --------------------------------------
>> Should staff_r, sysadm_r, secadm_r and auditadm_r be capable of doing 
>> a newrole to any of the previously listed roles? The alternative is to 
>> require staff_r to be used to transition to a different administrative 
>> roles.
> Roles do not transition. SELinux Users do .  You can define which roles 
> a SELinux user can reach.  And then you map Linux Users to SELinux users.
> 
> For example I can define an SELinux User "auditor"  And then I can give 
> the auditor user the staff_r and auditadm_r.  Then I would map dwalsh to 
> the auditor SELinux user.  Now when I log in, I will default to staff_r 
> and be able to newrole to auditadm_r.  I will not be able to newrole to 
> secadm_r or sysadm_r.

Ah ha, I was confused. In policy much older, once you newrole'd from 
staff_r to either secadm_r or sysadm_r, you couldn't newrole to the 
other admin role without returning to staff_r. This is no longer true, 
but it was the source of the misunderstanding.

> 
> Go to danwalsh.livejournal.com for a description on how to set this up.
>> Can we more clearly define what privilages sysadm_r has that overlap 
>> into secadm_r's realm? See below for examples.
>>
>> "secadm is the manager of SELinux policy", so only secadm_r can make 
>> modifications to the policy. Can sysadm_r view the policy? I would 
>> expect auditadm_r to not be permitted to even view it.
>>
> sysadm_r can view policy.
>> secadm_r can use the semanage tools, can sysadm_r?
>>
> No

Should secadm_r be able to use useradd? Or is it intended that a Unix 
user is added as sysadm_r and then you should newrole to secadm_r to 
setup any non-default SELinux permissions?

>> auditadm_r seems very clearly defined, is anything missing?

I take it that my description of auditadm is pretty solid then, I'm 
constructing an entry for the fedora wiki containing the information 
we've gleaned from this thread. I'll post it shortly and update accordingly.

>>
>>
>> Thanks,
>> Mike
>>
> 





More information about the redhat-lspp mailing list