From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Tue, 29 Sep 2009 15:50:38 -0400
Subject: [refpolicy] roles_unconfineduser.patch
In-Reply-To: <4AC25BA7.1060502@redhat.com>
References: <4A983C2C.8040507@redhat.com>
	<1254230695.10232.112.camel@gorn.columbia.tresys.com>
	<4AC20EBF.6010200@redhat.com>
	<1254235446.10232.115.camel@gorn.columbia.tresys.com>
	<4AC25BA7.1060502@redhat.com>
Message-ID: <1254253838.10232.132.camel@gorn.columbia.tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Tue, 2009-09-29 at 15:10 -0400, Daniel J Walsh wrote:
> On 09/29/2009 10:44 AM, Christopher J. PeBenito wrote:
> > On Tue, 2009-09-29 at 09:42 -0400, Daniel J Walsh wrote:
> >> On 09/29/2009 09:24 AM, Christopher J. PeBenito wrote:
> >>> On Fri, 2009-08-28 at 16:21 -0400, Daniel J Walsh wrote:
> >>>> http://people.fedoraproject.org/~dwalsh/SELinux/F12/roles_unconfineduser.patch
> >>>>
> >>>> Splitting out the unconfineduser policy from the unconfined domain so
> >>>> that you can leave unconfined_t but remove unconfined.pp
> >>>
> >>> I've been thinking about this for a while.  I don't have a problem with
> >>> this in principle, but I don't see how it would work with two modules.
> >>> The way I see it, the unconfineduser module would unconditionally depend
> >>> on the unconfined module (which defines what it means to be unconfined),
> >>> which would mean you couldn't remove the unconfined module while keeping
> >>> the unconfineduser module installed.
> >>>
> >>
> >> The trick I did to make it work is to add a dummy attribute and add another interface, 
> >>
> >>
> >>
> >> interface(`unconfined_domain',`
> >> 	gen_require(`
> >> 		attribute unconfined_services;
> >> 	')	
> >> 	unconfined_domain_noaudit($1)
> >> }
> >>
> >> unconfined_domain_noaudit has all the rules required for unconfined_domain.
> > 
> > This is the problem, the attribute should be in the _noaudit interface
> > instead, which breaks the desired behavior.
> > 
> 
> Huh?  Removing the attribute by removing the unconfined.pp causes all domains that used to the unconfined_domain()
> interface to no longer be unconfined_domains.  The types that linked against the unconfined_domain_noaudit() domain would still be unconfined.
> 
> unconfined_domain_noaudit in this case means unconfined_domains that are not services.

Basically what I'm saying is that there should be no unconfined domains
whatsoever on the system if the unconfined module is removed.  Your
implementation just exploits the static expansion of interfaces due to
the use of m4.

If/when the CIL implementation is functional, m4 expansion of interfaces
and require blocks will go away.  The dependence will be on the
interface itself.  Removing the unconfined module would remove the
unconfined_domain() and unconfined_domain_noaudit() interfaces, meaning
the unconfineduser module would have to be removed too since it
unconditionally requires the latter interface.

> kernel_t, rpm_t, unconfined_t.  We want these to be unconfined_domains no matter what unconfined_t would be eliminated if you removed unconfineduser.pp
> 
> I don't see ways that you can realistically run with out kernel_t and rpm_t being unconfined.

I'm just going to agree to disagree on this point.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150