From: dwalsh@redhat.com (Daniel J Walsh)
Date: Tue, 29 Sep 2009 16:01:37 -0400
Subject: [refpolicy] roles_unconfineduser.patch
In-Reply-To: <1254253838.10232.132.camel@gorn.columbia.tresys.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>
	<1254253838.10232.132.camel@gorn.columbia.tresys.com>
Message-ID: <4AC267A1.8040008@redhat.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 09/29/2009 03:50 PM, Christopher J. PeBenito wrote:
> 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.
> 
I think this comes down to the level of pain someone is willing to take.  I think we need a way to remove the ability to run uncofined services from a system.  But leave unconfined applications and unconfined user.  

Lots of people trust the administrator but distrust the services.  If they want all confined users we have that.  But we still either end up with the unconfined_t administrator or the sysadm_t administrator which is mostly an unconfined domain.

I would like to run a system where I have no unconfined services.  IE init_t, initrc_t. xinetd_t and others are confined.  While my administrator just works as unconfined_t.

Even in cil we can define an interface that the services can call that is separate from the unconfined_user() and unconfined_services() maybe?  Then have unconfined_services() defined in unconfinedservices.pp package remove unconfinedservices.pp to remove the unconfined_services and unconfined_user() maybe have unconfined_domain defined in unconfineduser.pp.
Removing this removes both.