On Fri, 2007-01-26 at 12:18 -0500, bx wrote:
Hello,
Let me apologize if this is the wrong place to ask this question,
but I figure that those well versed in SELinux can help me. I have
been reading a ton about SELinux and Flask, and I haven't found
anything that answered my question.
I am working on creating a security policy from scratch
I'd suggest leveraging the reference policy instead as a baseline, then
customize it as desired.
http://oss.tresys.com/projects/refpolicy
and followed the tutorial the IBM published
(
http://www-128.ibm.com/developerworks/linux/library/l-selinux.html).
After taking a look at the bare bones policy.conf file it generated,
it got me thinking- I don't need to have something as granular as
SELinux allows me to be. In fact it would simplify things if I could
change the granularity. How would SELinux be affected if I were to
remove some of the class definitions and took anything that referred
to those classes out of my policy? Would SELinux just not enforce
anything on those types of objects, would SELinux completely disallow
all use of those objects or would it just break SELinux?
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.
--
Stephen Smalley
National Security Agency