[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: SELinux Policy/Flask Classes from scratch
- From: Stephen Smalley <sds tycho nsa gov>
- To: bx <galaxy4sale gmail com>
- Cc: fedora-selinux-list redhat com
- Subject: Re: SELinux Policy/Flask Classes from scratch
- Date: Fri, 26 Jan 2007 12:50:30 -0500
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
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]