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
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
