From: mgrepl@redhat.com (Miroslav Grepl) Date: Mon, 23 Nov 2009 18:17:37 +0100 Subject: [refpolicy] services_nut.patch In-Reply-To: <1258992547.4516.17.camel@localhost> References: <4AFC823D.3090202@redhat.com> <1258381900.5120.16.camel@localhost> <4B019ACD.4010406@redhat.com> <1258901980.2423.16.camel@localhost> <4B0A88B7.1050903@redhat.com> <1258987001.3109.6.camel@localhost> <1258989561.27504.643.camel@gorn.columbia.tresys.com> <1258992270.4516.13.camel@localhost> <1258992547.4516.17.camel@localhost> Message-ID: <4B0AC3B1.20003@redhat.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 11/23/2009 05:09 PM, Stefan Schulze Frielinghaus wrote: > On Mon, 2009-11-23 at 17:04 +0100, Stefan Schulze Frielinghaus wrote: > >> On Mon, 2009-11-23 at 10:19 -0500, Christopher J. PeBenito wrote: >> >>> On Mon, 2009-11-23 at 15:36 +0100, Stefan Schulze Frielinghaus wrote: >>> >>>> On Mon, 2009-11-23 at 14:05 +0100, Miroslav Grepl wrote: >>>> [...] >>>> >>>>>> Another question, what is the intention of the following >>>>>> >>>>>> permissive upsd_t; >>>>>> permissive upsdrvctl_t; >>>>>> permissive upsmon_t; >>>>>> >>>>>> Does that make the domain permissive by default? >>>>>> >>>>> Yes, it does. We add new domains to permissive so we can fix all the avc's without blocking of functionality apps. >>>>> >>>> But not for refpolicy, right? Yes, I meant in Fedora. >>>> I cannot find any such statement in the >>>> policy modules of refpolicy. At least I wouldn't expect such a behavior >>>> from modules of refpolicy. I guess we can remove those three lines. >>>> >>>> If you are fine with the merge of both policies then we can commit it >>>> (after the port change of course). >>>> >>> My policy is to not have permissive domains in upstream refpolicy. If >>> the modules need more work the patch is dropped. Otherwise the >>> permissive is dropped. >>> >> Yes, this is what I thought. Since I use the NUT policy for about a year >> and it has some intersection with Miroslavs policy (he uses NUT with a >> ups attached via USB and my via SNMP), I would say it is stable enough. >> > Just to make it precise. In general it is stable but I will wait for an > OK from Miroslav, I will check it and let you know. > then I'm going to rearrange some allow rules according > to the style-guidelines and will submit the patch again. > >