From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Fri, 18 Mar 2011 09:38:33 -0400
Subject: [refpolicy] Question: and the policy grows...
In-Reply-To: <1300393670.31755.24.camel@tesla.lan>
References: <1300369855.30425.14.camel@tesla.lan>	<4D8219D9.7080504@redhat.com>
	<1300377867.30425.40.camel@tesla.lan>	<4D823A60.9020107@redhat.com>
	<1300390804.31755.6.camel@tesla.lan>	<4D826724.4030908@redhat.com>
	<1300393670.31755.24.camel@tesla.lan>
Message-ID: <4D836059.8030806@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 03/17/11 16:27, Guido Trentalancia wrote:
> On Thu, 17/03/2011 at 15.55 -0400, Daniel J Walsh wrote:
>> On 03/17/2011 03:40 PM, Guido Trentalancia wrote:
>>>>>>> In any case, we haven't found a solution (or at least a methodology).
>>>>>>> The only (obvious) one I can foresee at the moment is periodically
>>>>>>> restarting from scratch (i.e. creating a new generation of refpolicy
>>>>>>> from scratch every x years). Which is massive work.
>>>>>>>
>>>>> Yes and going to generate a large amount of errors, since most bugs are
>>>>> caused by running apps in different ways.
>>>>>
>>>>>>> From the Changelog I take that refpolicy started on June 2005. Software
>>>>>>> version numbers does not necessarily mean anything, but just to give an
>>>>>>> idea, on June 2005, we had the following versions (taken at random):
>>>>>>>
>>>>>>> kernel 2.6.12 (now 2.6.38)
>>>>>>> Linux-PAM 0.79 (now 1.1.3)
>>>>>>> gtk+ 2.6.8 (now 3.0)
>>>>>>> evolution 2.3.3 (now 2.32.2)
>>>>>>> ...
>>>>> And refpolicy was an attempt to make all rules == example policy when
>>>>> the port happened, so most of the original rules come from Prior to 2002.
>>>>>>>
>>>>>>> I'd be very happy to hear from others...
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Guido
>>>>>>>
>>>>> I think if we ever get to the next generation of policy and could start
>>>>> removing rules. easily this would help.
>>> I didn't get this. What could help ?
>>>
>>
>> Right now removing access is difficult, you really need to be able to
>> start with the entire policy and build.  If we improved the tool chain,
>> you could remove rules.  Then people could experiment with removing
>> rules and it the system still works, suggest patches that remove allow
>> rules.
> 
> Trial and error. Can you think of anything else behind that ? Or
> otherwise just confirm that anything else is impossible to achieve ?
> 
> Because you know, automated trial and error methods are easy, cheap and
> usually quite powerful. But human trial and error can be quite expensive
> in practice.
> 
>> Imagine you could write policy module that said
>>
>> remove  application_domain user_tty_device_t:chr_file open;
>>
>> [SNIP]
> 
> Yes. I get the point. The operator "remove" always having precedence
> over "add". Hopefully we'll have that one day. In the end it shouldn't
> be too hard to implement...
> 
> You found 1 methodology.

There has been work on this type of policy functionality.  See CIL
efforts in the archive.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com