All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel J Walsh <dwalsh@redhat.com>
To: Steve Grubb <sgrubb@redhat.com>, linux-audit@redhat.com
Cc: Stephen Smalley <stephen.smalley@gmail.com>,
	selinux <selinux@tycho.nsa.gov>
Subject: Re: [RFC][PATCH] selinux: Report result in avc messages
Date: Wed, 30 Apr 2014 09:34:57 -0400	[thread overview]
Message-ID: <5360FC01.9090904@redhat.com> (raw)
In-Reply-To: <1734421.ihMzWMu7WD@x2>


On 04/30/2014 09:29 AM, Steve Grubb wrote:
> On Wednesday, April 30, 2014 08:59:50 AM Daniel J Walsh wrote:
>> How about permitted rather then allowed.
> I think permitted is already in an AVC.
Not sure where.
>
>> On 04/29/2014 10:59 PM, Eric Paris wrote:
>>> On Tue, 2014-04-29 at 16:54 -0700, Stephen Smalley wrote:
>>>> Requested for Android in order to distinguish denials that are not in
>>>> fact breaking anything yet due to permissive domains versus denials
>>>> that are being enforced, but seems generally useful.  result field was
>>>> already in the selinux audit data structure and was being passed to
>>>> avc_audit() but wasn't being used.  Seems to cause no harm to ausearch
>>>> or audit2allow to add it as a field.  Comments?
>>> I think it's a great idea, but I'm worried that Steve is going to get
>>> grumpy because an AVC record is going to have a result= field which is
>>> similar, but not necessarily related to the res= field of a SYSCALL
>>> record. 
> I think that I'll have to parse this field no matter what. Its probably that 
> important. In the syscall, we use success= to be the final determination.
>
>
>>> Seems easily confused (although probably 9999 times out of
>>> 10000 they will be the same)
> Why would this ever not be correct? Are there times when we get an AVC with a 
> denial _and_ the syscall completes successfully?
>
> I'd suggest using res= since its in the audit dictionary and means exactly 
> what you are wanting to use it for. In it, 1 is success, 0 is failure.
>
I have seen AVC's where the success=yes in enforcing mode.  Basically
the kernel takes a different code path and the syscall succeeds.  Most
of these end up as dontaudits.
>>> So while I wholeheartedly think we should take the idea, I wonder if
>>> someone can dream up a name that isn't confusingly similar...
>>>
>>> I can't think of anything...
> There is thesaurus.com. :-)
>
> consequence, outcome, effect, reaction,  conclusion, verdict, decision, 
> judgement, finding, ruling, answer, solution, recommendation, order,  ...
>
> -Steve

WARNING: multiple messages have this Message-ID (diff)
From: Daniel J Walsh <dwalsh@redhat.com>
To: Steve Grubb <sgrubb@redhat.com>, linux-audit@redhat.com
Cc: selinux <selinux@tycho.nsa.gov>, Eric Paris <eparis@redhat.com>
Subject: Re: [RFC][PATCH] selinux: Report result in avc messages
Date: Wed, 30 Apr 2014 09:34:57 -0400	[thread overview]
Message-ID: <5360FC01.9090904@redhat.com> (raw)
In-Reply-To: <1734421.ihMzWMu7WD@x2>


On 04/30/2014 09:29 AM, Steve Grubb wrote:
> On Wednesday, April 30, 2014 08:59:50 AM Daniel J Walsh wrote:
>> How about permitted rather then allowed.
> I think permitted is already in an AVC.
Not sure where.
>
>> On 04/29/2014 10:59 PM, Eric Paris wrote:
>>> On Tue, 2014-04-29 at 16:54 -0700, Stephen Smalley wrote:
>>>> Requested for Android in order to distinguish denials that are not in
>>>> fact breaking anything yet due to permissive domains versus denials
>>>> that are being enforced, but seems generally useful.  result field was
>>>> already in the selinux audit data structure and was being passed to
>>>> avc_audit() but wasn't being used.  Seems to cause no harm to ausearch
>>>> or audit2allow to add it as a field.  Comments?
>>> I think it's a great idea, but I'm worried that Steve is going to get
>>> grumpy because an AVC record is going to have a result= field which is
>>> similar, but not necessarily related to the res= field of a SYSCALL
>>> record. 
> I think that I'll have to parse this field no matter what. Its probably that 
> important. In the syscall, we use success= to be the final determination.
>
>
>>> Seems easily confused (although probably 9999 times out of
>>> 10000 they will be the same)
> Why would this ever not be correct? Are there times when we get an AVC with a 
> denial _and_ the syscall completes successfully?
>
> I'd suggest using res= since its in the audit dictionary and means exactly 
> what you are wanting to use it for. In it, 1 is success, 0 is failure.
>
I have seen AVC's where the success=yes in enforcing mode.  Basically
the kernel takes a different code path and the syscall succeeds.  Most
of these end up as dontaudits.
>>> So while I wholeheartedly think we should take the idea, I wonder if
>>> someone can dream up a name that isn't confusingly similar...
>>>
>>> I can't think of anything...
> There is thesaurus.com. :-)
>
> consequence, outcome, effect, reaction,  conclusion, verdict, decision, 
> judgement, finding, ruling, answer, solution, recommendation, order,  ...
>
> -Steve

  reply	other threads:[~2014-04-30 13:34 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-29 23:54 [RFC][PATCH] selinux: Report result in avc messages Stephen Smalley
2014-04-30  0:22 ` William Roberts
2014-04-30  2:59 ` Eric Paris
2014-04-30  2:59   ` Eric Paris
2014-04-30 12:59   ` Daniel J Walsh
2014-04-30 12:59     ` Daniel J Walsh
2014-04-30 13:29     ` Steve Grubb
2014-04-30 13:29       ` Steve Grubb
2014-04-30 13:34       ` Daniel J Walsh [this message]
2014-04-30 13:34         ` Daniel J Walsh
2014-04-30 15:18         ` Stephen Smalley
2014-04-30 15:18           ` Stephen Smalley
2014-04-30 15:38           ` Stephen Smalley
2014-04-30 15:38             ` Stephen Smalley
2014-04-30 15:48             ` William Roberts
2014-04-30 15:48               ` William Roberts
2014-04-30 16:01               ` Steve Grubb
2014-04-30 16:08                 ` Stephen Smalley
2014-04-30 16:20                   ` William Roberts
2014-04-30 16:20                     ` William Roberts
2014-05-01 19:09                   ` Paul Moore
2014-05-01 19:09                     ` Paul Moore
2014-05-01 20:11                     ` Stephen Smalley
2014-05-01 20:11                       ` Stephen Smalley
2014-05-02 19:47                       ` Paul Moore
2014-05-02 19:47                         ` Paul Moore
2014-04-30 15:52             ` Eric Paris
2014-04-30 15:52               ` Eric Paris
2014-04-30 12:56 ` 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=5360FC01.9090904@redhat.com \
    --to=dwalsh@redhat.com \
    --cc=linux-audit@redhat.com \
    --cc=selinux@tycho.nsa.gov \
    --cc=sgrubb@redhat.com \
    --cc=stephen.smalley@gmail.com \
    /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.