On 1/26/07, Stephen Smalley <sds(a)tycho.nsa.gov> wrote:
I'd suggest leveraging the reference policy instead as a baseline, then
customize it as desired.
http://oss.tresys.com/projects/refpolicy
I took a look at the reference policy and I am not sure how it can help
me. I am
not trying to use SELinux to constrain programs and daemons to
sandboxes, instead I would like to use it to create restricted system
administrator accounts. Although in the future, I may want to end up
hardening apache, etc, however at this point, that is not my focus. My
approach would be similar to the targeted policy, in which there is an
"unconfined" base domain in which most things roam. I understand that in
theory the reference policy would be a good approach due to its modular
approach, however I do not know where to start to get myself my base
unconfined layer I want. I am open to suggestions.
At present, removing kernel classes would lead to permission denials
or
breakage. See the thread starting with:
http://marc.theaimsgroup.com/
?l=selinux&m=116499002502432&w=2
Note however this isn't just a matter of granularity of
protection, but
rather completeness of protection; if you were to disable SELinux
enforcement for a given object class, then you are removing all control
on those objects, enabling them to serve as a way of bypassing policy.
Changing the granularity of protection would just mean folding multiple
classes together, e.g. handle all of the file-related classes as one,
which you can achieve in policy by use of macros rather than needing to
change the kernel.
This makes absolute sense, thank you. I will use macros to create the
granularity I desire.
I appreciate your help,
Rebecca