-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/28/2010 02:47 PM, Joshua Brindle wrote:
> 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@xxxxxxxxxx>
>>>> 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@xxxxxxxxxxxxx
> with
> the words "unsubscribe selinux" without quotes as the message.
I think the best solution is to start expanding attributes so we at
least have a chance at a match, without changing the weighting.
Secondly would be to start collecting oddball returns by the tool and
sending them to Karl.
I just tried a few and they came up with the correct interface.
Lets ask dgrift, mgrepl, Chris and other prolific policy writers to use
this tool to see if the interface matches are working for them. The
problem is people who write enough policy, tend to know which interface
to use, so they do not necessarily use audit2allow -R.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkvYhhcACgkQrlYvE4MpobMYjgCffoR0aerRBPvKu7BsvD1cZRxi
k30AoOqKOQsiZH6BPBY77Oxq9wEY6PRC
=dTwd
-----END PGP SIGNATURE-----
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
