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

[Daniel J Walsh]

Michael C Thompson wrote:
> 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?
I don't think so.  secadm can only manipulate the selinux mapping.  We 
might want a boolean though since creating a user is going to be a royal 
pain in the butt.  (As my blog shows).
>
>>> 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.
Yes looks good.  Now if we can just get /etc/auditd/ created :^)
>
>>>
>>>
>>> Thanks,
>>> Mike
>>>
>>
>
>