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

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.

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.


--
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:12 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 17:53                     ` Karl MacMillan
2010-04-28 18:12                       ` Joshua Brindle [this message]
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=4BD87A97.9010309@tresys.com \
    --to=jbrindle@tresys.com \
    --cc=cpebenito@tresys.com \
    --cc=dwalsh@redhat.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.