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