Re: refpolicy is missing on lots of hits with audit2allow -R.

[Joshua Brindle <jbrindle@tresys.com>]

Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 04/28/2010 02:12 PM, Joshua Brindle wrote:
>> Karl MacMillan wrote:
>>> On Wed, Apr 28, 2010 at 11:34 AM, Daniel J Walsh<dwalsh@redhat.com>
>>> wrote:
>> <snip>>
>>>> I would argue that
>>>>
>>>> allow X etc_t:file read;
>>>> allow X configfile:file read;
>>>>
>>>> Should be weighted equivalently if etc_t is a configfile or only
>>>> slightly heavier, and just because etc_runtime_t or some other random
>>>> types are configfile does not mean we need to add weight.
>>>>
>> I'm going to weigh in here even though policy isn't normally my thing.
>>
>> I am very against reducing distance based on attribute match over
>> individual unrelated types. allow X configfile:file read should be the
>> exact same distance as having an allow rule for every type in configfile
>> in the interface, otherwise you have inconsistent behavior and are
>> rewarding interfaces that are overly broad.
>>
> I agree but the question is on an AVC that needs
>
> allow $1 etc_t:file read;
>
>
> Which is a better match
>
> allow $1 configfile:file read;
>
> Or
>
> allow $1 etc_t:file { read write };
>
>> The reason for using sepolgen is to find the best match, not the most
>> broad, if we wanted that we could make sepolgen 1000% less complicated
>> and just return allow domain filetype:file *;
>>
>> I suppose there is a fundamental difference in the use of the tool, the
>> people I know that use it use it to find the best match, the way you
>> want to use it is to fix the denial any way possible. These 2 usages
>> conflict and we can't have people thinking they are making secure policy
>> when in fact they aren't.
>>
>
> Thats Bullshit.  I am trying to get the best match.  The example I
> showed earlier the tool was getting way off, because it did not take
> into effect attributes.  The access returned for a getattr was to allow
> the domain to delete the file.
>

Fair enough. It seems like it would work as expected if interfaces were 
relatively side effect free though (eg., files_read_etc_files shouldn't 
have the side effect of reading all config files, perhaps a new 
interface called files_read_config_files should be used instead).

I guess the big problem is that without looking at the interface (and 
unraveling all the interface calls within) the user can't actually 
determine what the matched interfaces do.

I agree with Karl about penalizing exec and delete though, even though 
exec really isn't necessary to execute something, all you need is read 
access.

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.