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.
