From: dominick.grift@gmail.com (Dominick Grift)
Date: Wed, 23 Oct 2013 22:22:25 +0200
Subject: [refpolicy] I think we made a large mistake when we designed
 apache_content_template.
In-Reply-To: <52682701.6030900@redhat.com>
References: <52680DF1.3000700@redhat.com> <1382557103.3041.120.camel@d30>
	<52682701.6030900@redhat.com>
Message-ID: <1382559745.3041.146.camel@d30>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Wed, 2013-10-23 at 15:44 -0400, Daniel J Walsh wrote:

> > 
> Well we do have some tooling that understands seinfo and sesearch.
> 
> But the ability for xyz_t to write to abc_file_t and xyz_file_t are probably
> two different concepts.  By convention is is more likely that we would want to
> have a man page generated mentioning the relationship between xyz_t process
> type and xyz_file_t, but ignore abc_file_t, or at least treat it as a second
> class relationship.

Yes, its just a tough issue

Heres another one of my brainstorm sessions ( brace yourselfs :P)

identifiers are configurable ( this was probably done for a reason ), If
we want our users to really use selinux, we better expect them to "break
our rules"

We can create a "primary control" of the policy but then we probably
give up much of SELinuxes flexibility, and configurability.

But then again the "primary control" would be optional, and so "power"
users could just opt-out. They do not need a tool to tell them what not
to do (Come to think about it, relying on a tool for security seems like
a sub-optimal idea to me)

I think CIL could be a great opportunity build a "primary control" on.
Its flexible, powerful, no pre-processing,, and everything can be
changed on the fly because the policy is in plain text on the system
probably

so you would get: primary-control -> cil -> selinux

keep the primary control as flexible as possible, only make it enforce,
strictly what we need it to enforce

So i think there are two things to tackle here

(ref|cil)policy 3.0:

back to the basics: only provide, maintain a solid base, no contrib

this base should be a base for all, and it should be made with cil|
primary control in mind

primary-control 1.0:

The ultimate policy ide, its like slide on steriods. it will enforce
standards and will be the primary interface with cil/selinux

It will not be a policy wizard ( click through menus ) and it will be as
flexible as possible, enforce as little as possible, but it will be made
so that tools can rely on certain standards

Then i guess we should make it so that the policy can be manipulated
only via primary control to ensure that one doesnt by pass it (unless
admin configures things explicity to not use primary control in which
case admin understands that tools that rely on primary control 1.0 and
ref|cilpolicy 3.0 will break. (for power users thats not a problem
anyways as long as we do not shut them out (e.g. we give both scenarios
attention. not neglect the power users ( like one neglected monolithic
policy when one implemented modular policy )