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
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.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
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.
unconfined_domain_noaudit(unconfined_t)
unconfined_domain_noaudit(kernel_t)
unconfined_domain_noaudit(rpm_t)
unconfined_domain(init_t)
unconfined_domain(initrc_t)
...
The only thing in unconfined.te is
policy_module(unconfined, 3.0.1)
########################################
#
# Declarations
#
attribute unconfined_services;
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.
--
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150
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.
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.
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
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.
On Wed, 30 Sep 2009, Daniel J Walsh <[email protected]> wrote:
> 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.
We did have usable systems for years before the concept of an "unconfined
domain" was invented. Of course we did occasionally run into problems like
the kernel Oops on shutdown if kernel_t was not permitted to create a UDP
socket.
In a more general sense, rpm_t needs to be able to create files with few
restrictions (we could restrict it from accessing /home but that would
involve some pain). kernel_t needs to be able to mess with other processes
and network operations in any way that it desires but should have no
filesystem access other than that which is required to run init and modprobe
(or maybe hotplug too - what's the latest plan for kernel support of new
devices?).
--
russell at coker.com.au
http://etbe.coker.com.au/ My Main Blog
http://doc.coker.com.au/ My Documents Blog
On 09/30/2009 03:56 AM, Russell Coker wrote:
> On Wed, 30 Sep 2009, Daniel J Walsh <[email protected]> wrote:
>> 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.
>
> We did have usable systems for years before the concept of an "unconfined
> domain" was invented. Of course we did occasionally run into problems like
> the kernel Oops on shutdown if kernel_t was not permitted to create a UDP
> socket.
>
> In a more general sense, rpm_t needs to be able to create files with few
> restrictions (we could restrict it from accessing /home but that would
> involve some pain). kernel_t needs to be able to mess with other processes
> and network operations in any way that it desires but should have no
> filesystem access other than that which is required to run init and modprobe
> (or maybe hotplug too - what's the latest plan for kernel support of new
> devices?).
>
Do you use NFS? AFS? Kernel threads need access to the file system