From: Steve Grubb <sgrubb@redhat.com>
To: 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:29:58 -0400 [thread overview]
Message-ID: <1734421.ihMzWMu7WD@x2> (raw)
In-Reply-To: <5360F3C6.4090501@redhat.com>
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.
> 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.
> > 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: Steve Grubb <sgrubb@redhat.com>
To: 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:29:58 -0400 [thread overview]
Message-ID: <1734421.ihMzWMu7WD@x2> (raw)
In-Reply-To: <5360F3C6.4090501@redhat.com>
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.
> 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.
> > 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
next prev parent reply other threads:[~2014-04-30 13:29 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 [this message]
2014-04-30 13:29 ` Steve Grubb
2014-04-30 13:34 ` Daniel J Walsh
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=1734421.ihMzWMu7WD@x2 \
--to=sgrubb@redhat.com \
--cc=linux-audit@redhat.com \
--cc=selinux@tycho.nsa.gov \
--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.