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 -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
