All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel J Walsh <dwalsh@redhat.com>
To: Joshua Brindle <jbrindle@tresys.com>
Cc: Karl MacMillan <kmacmillan@tresys.com>,
	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 14:36:00 -0400	[thread overview]
Message-ID: <4BD88010.9050906@redhat.com> (raw)
In-Reply-To: <4BD87A97.9010309@tresys.com>

-----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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkvYgBAACgkQrlYvE4MpobNo3ACeIkGbGm9mWWUaAVPkA8B64YTS
zMkAn3PhjVrB1cw0jSIZo7bUmmcK58e+
=A6kc
-----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.

  reply	other threads:[~2010-04-28 18:36 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
2010-04-28 15:34                   ` Daniel J Walsh
2010-04-28 17:53                     ` Karl MacMillan
2010-04-28 18:12                       ` Joshua Brindle
2010-04-28 18:36                         ` Daniel J Walsh [this message]
2010-04-28 18:47                           ` Joshua Brindle
2010-04-28 19:01                             ` Daniel J Walsh
2010-04-28 18:42                         ` Karl MacMillan
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=4BD88010.9050906@redhat.com \
    --to=dwalsh@redhat.com \
    --cc=cpebenito@tresys.com \
    --cc=jbrindle@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.