On 1/26/07, <b class="gmail_sendername">Stephen Smalley</b> <<a href="mailto:sds@tycho.nsa.gov">sds@tycho.nsa.gov</a>> wrote:
<blockquote>
<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I'd suggest leveraging the reference policy instead as a baseline, then
<br>customize it as desired.<br><a href="http://oss.tresys.com/projects/refpolicy">http://oss.tresys.com/projects/refpolicy</a><br><br></blockquote></div>
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.<br>
<br clear="all">
<blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">At present, removing kernel classes would lead to permission denials or<br>
breakage. See the thread starting with:<br>
<a href="http://marc.theaimsgroup.com/">http://marc.theaimsgroup.com/</a></blockquote>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">?l=selinux&m=116499002502432&w=2<br>Note however this isn't just a matter of granularity of protection, but
<br>rather completeness of protection; if you were to disable SELinux<br>enforcement for a given object class, then you are removing all control<br>on those objects, enabling them to serve as a way of bypassing policy.<br>
Changing the granularity of protection would just mean folding multiple<br>classes together, e.g. handle all of the file-related classes as one,<br>which you can achieve in policy by use of macros rather than needing to<br>
change the kernel.</blockquote>
<br>
This makes absolute sense, thank you. I will use macros to create the granularity I desire.<br>
<br>
<br>
I appreciate your help,<br>
Rebecca<br>
</blockquote>