From: Daniel J Walsh <dwalsh@redhat.com>
To: Karl MacMillan <kmacmillan@tresys.com>
Cc: SELinux <selinux@tycho.nsa.gov>,
"Christopher J. PeBenito" <cpebenito@tresys.com>
Subject: Re: refpolicy is missing on lots of hits with audit2allow -R.
Date: Wed, 28 Apr 2010 11:34:42 -0400 [thread overview]
Message-ID: <4BD85592.10201@redhat.com> (raw)
In-Reply-To: <n2g10143821004280725qcf3ebaf8n44eb53504aa32feb@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 04/28/2010 10:25 AM, Karl MacMillan wrote:
> On Fri, Apr 23, 2010 at 11:09 AM, Daniel J Walsh <dwalsh@redhat.com> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> I do not totally understand your matching, but I thought if you looked for
>>
>> allow TYPE etc_t:file getattr;
>>
>> You could get extra matches.
>>
>
> That's essentially what I do.
>
>> I was thinking in terms of sepolgen-ifgen would take every type and
>> expand the attributes for the type then if you find attribute that
>> matches, not add weight.
>>
>
> I think you are missing what the core problem is - it's easy to find
> interfaces that match this access. Many interfaces (including
> files_read_etc_files) include a rule that directly matches getattr on
> etc_t files. So I don't really need to do attribute expansion to get
> enough matches.
>
> The key problem is finding the _best_ match, which I define as the
> interface that allows the requested access with the least amount of
> "extra" access. That's what the distance measure is for - it is a
> measure of extra access. So I add extra distance for access to
> unrelated types, extra permissions, returning a write interface when a
> read was requested, etc. So when you add access to a broad attribute
> in files_read_etc_files the distance measure - as currently shipped -
> adds more distance for 1 type (the attribute). However, when I expand
> the attribute the distance goes up because it becomes clear that the
> interface is in fact allowing a _lot_ of access.
>
> This seems correct to me, hence my request to return what was intended
> to be a narrow interface back to that narrow definition.
>
> However, there are some things that I can do to make this distance
> algorithm better:
>
> 1. Don't penalize as much for access that involves container object
> classes, such as directory, in an attempt to not penalize for access
> that is actually related.
>
> 2. Detect execute and add a big penalty for interfaces that allow
> execute when it wasn't requested (similar to what I do with write).
>
> I'm also open to other suggestions. I don't think that what I have is
> perfect. However, none of this will fix the fact that the
> files_read_etc_files shipped in Fedora grants broad access. If
> everyone agrees that we want that interface to match regardless then I
> think we are going to have to add some other mechanism to the matching
> algorithm. Perhaps some "hinting" mechanism to let the policy author
> to tell sepolgen to prefer certain interfaces. I might even be able to
> automatically derive this from how popular the interface is in current
> policies.
>
> Karl
I understand, although I don't agree with penalizying because you match
on an attribute, Currently if I wrote this interface the way I want,
with just the attribute your algorithm would not find it at all.
files_read_etc_files to me means match all config files in the /etc
directory, just because some random application decides to change the
context of /etc/hostname to etc_runtime_t or net_conf_t, we should not
need to change all domains that are supposed to read generic files in
/etc. Especially when I don't even need to read them.
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.
But when the attribute adds more weight then "write" does, I think the
algorithm is broken.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkvYVZEACgkQrlYvE4MpobPf6QCfY6wAi3VqF9s3do7QwAoQ8UrA
PZwAoN5L0WvquabGFHNfINoJq4MkOy8S
=l2u0
-----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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
next prev parent reply other threads:[~2010-04-28 15:34 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-19 14:33 refpolicy is missing on lots of hits with audit2allow -R Daniel J Walsh
2010-04-19 15:53 ` Karl MacMillan
2010-04-20 14:37 ` Karl MacMillan
2010-04-20 18:09 ` Christopher J. PeBenito
2010-04-21 14:04 ` Daniel J Walsh
2010-04-22 1:53 ` Karl MacMillan
2010-04-22 13:04 ` Daniel J Walsh
2010-04-22 14:25 ` Karl MacMillan
2010-04-22 13:38 ` Daniel J Walsh
2010-04-22 14:29 ` Karl MacMillan
2010-04-22 19:16 ` Karl MacMillan
2010-04-23 15:09 ` Daniel J Walsh
2010-04-28 14:25 ` Karl MacMillan
2010-04-28 15:34 ` Daniel J Walsh [this message]
2010-04-28 17:53 ` Karl MacMillan
2010-04-28 18:12 ` Joshua Brindle
2010-04-28 18:36 ` Daniel J Walsh
2010-04-28 18:47 ` Joshua Brindle
2010-04-28 19:01 ` Daniel J Walsh
2010-04-28 18:42 ` Karl MacMillan
2010-04-28 15:34 ` Daniel J Walsh
2010-05-13 19:37 ` Stephen Smalley
2010-04-20 14:46 ` Daniel J Walsh
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BD85592.10201@redhat.com \
--to=dwalsh@redhat.com \
--cc=cpebenito@tresys.com \
--cc=kmacmillan@tresys.com \
--cc=selinux@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.