9:59 p.m.
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. Seems easily confused (although probably 9999 times out of
10000 they will be the same)
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...
-Eric
7:59 a.m.
New subject: [RFC][PATCH] selinux: Report result in avc messages
How about permitted rather then allowed.
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. Seems easily confused (although probably 9999 times out of
10000 they will be the same)
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...
-Eric
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
8:29 a.m.
New subject: [RFC][PATCH] selinux: Report result in avc messages
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
8:34 a.m.
New subject: [RFC][PATCH] selinux: Report result in avc messages
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
10:18 a.m.
New subject: [RFC][PATCH] selinux: Report result in avc messages
I could make it permissive=0 or permissive=1 if that is less
confusing. It doesn't necessarily correspond to the result of the
system call, just the avc_has_perm call, as e.g. the kernel checks
CAP_DAC_OVERRIDE and falls back to CAP_DAC_READ_SEARCH if only
read/search access was requested, and there are other cases where a
permission denial has a side effect rather than preventing the system
call (e.g. CAP_FSETID).
On Wed, Apr 30, 2014 at 6:34 AM, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
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
10:38 a.m.
New subject: [RFC][PATCH] selinux: Report result in avc messages
Attached patch switches to reporting permissive=0|1 and only does it
for avc: denied messages.
On Wed, Apr 30, 2014 at 8:18 AM, Stephen Smalley
<stephen.smalley(a)gmail.com> wrote:
I could make it permissive=0 or permissive=1 if that is less
confusing. It doesn't necessarily correspond to the result of the
system call, just the avc_has_perm call, as e.g. the kernel checks
CAP_DAC_OVERRIDE and falls back to CAP_DAC_READ_SEARCH if only
read/search access was requested, and there are other cases where a
permission denial has a side effect rather than preventing the system
call (e.g. CAP_FSETID).
On Wed, Apr 30, 2014 at 6:34 AM, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
>
> 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
>
10:48 a.m.
New subject: [RFC][PATCH] selinux: Report result in avc messages
My only nit would be the variable name result....would it be better named
is_permissive or something?
Otherwise LGTM. From the Android camp, this will be very helpful.
On Apr 30, 2014 8:43 AM, "Stephen Smalley" <stephen.smalley(a)gmail.com>
wrote:
Attached patch switches to reporting permissive=0|1 and only does it
for avc: denied messages.
On Wed, Apr 30, 2014 at 8:18 AM, Stephen Smalley
<stephen.smalley(a)gmail.com> wrote:
> I could make it permissive=0 or permissive=1 if that is less
> confusing. It doesn't necessarily correspond to the result of the
> system call, just the avc_has_perm call, as e.g. the kernel checks
> CAP_DAC_OVERRIDE and falls back to CAP_DAC_READ_SEARCH if only
> read/search access was requested, and there are other cases where a
> permission denial has a side effect rather than preventing the system
> call (e.g. CAP_FSETID).
>
> On Wed, Apr 30, 2014 at 6:34 AM, Daniel J Walsh <dwalsh(a)redhat.com>
wrote:
>>
>> 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
>>
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
11:01 a.m.
New subject: [RFC][PATCH] selinux: Report result in avc messages
On Wednesday, April 30, 2014 08:48:31 AM William Roberts wrote:
My only nit would be the variable name result....would it be better
named
is_permissive or something?
That adds more bytes. My personal taste would be to abbreviate it to save
bytes. They add up when you have 100's of thousands of events per day.
-Steve
Otherwise LGTM. From the Android camp, this will be very helpful.
On Apr 30, 2014 8:43 AM, "Stephen Smalley" <stephen.smalley(a)gmail.com>
wrote:
> Attached patch switches to reporting permissive=0|1 and only does it
> for avc: denied messages.
>
> On Wed, Apr 30, 2014 at 8:18 AM, Stephen Smalley
>
> <stephen.smalley(a)gmail.com> wrote:
> > I could make it permissive=0 or permissive=1 if that is less
> > confusing. It doesn't necessarily correspond to the result of the
> > system call, just the avc_has_perm call, as e.g. the kernel checks
> > CAP_DAC_OVERRIDE and falls back to CAP_DAC_READ_SEARCH if only
> > read/search access was requested, and there are other cases where a
> > permission denial has a side effect rather than preventing the system
> > call (e.g. CAP_FSETID).
> >
> > On Wed, Apr 30, 2014 at 6:34 AM, Daniel J Walsh <dwalsh(a)redhat.com>
>
> wrote:
> >> 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
>
> --
> Linux-audit mailing list
> Linux-audit(a)redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
11:08 a.m.
New subject: [RFC][PATCH] selinux: Report result in avc messages
The revised patch switched from result=allowed|denied to
permissive=0|1 in the avc message. I think Bill's point was with
respect to the code, which still internally is passing around the
result of the decision and inferring the permissive state from it,
rather than the output string itself.
On Wed, Apr 30, 2014 at 9:01 AM, Steve Grubb <sgrubb(a)redhat.com> wrote:
On Wednesday, April 30, 2014 08:48:31 AM William Roberts wrote:
> My only nit would be the variable name result....would it be better named
> is_permissive or something?
That adds more bytes. My personal taste would be to abbreviate it to save
bytes. They add up when you have 100's of thousands of events per day.
-Steve
> Otherwise LGTM. From the Android camp, this will be very helpful.
> On Apr 30, 2014 8:43 AM, "Stephen Smalley"
<stephen.smalley(a)gmail.com>
>
> wrote:
> > Attached patch switches to reporting permissive=0|1 and only does it
> > for avc: denied messages.
> >
> > On Wed, Apr 30, 2014 at 8:18 AM, Stephen Smalley
> >
> > <stephen.smalley(a)gmail.com> wrote:
> > > I could make it permissive=0 or permissive=1 if that is less
> > > confusing. It doesn't necessarily correspond to the result of the
> > > system call, just the avc_has_perm call, as e.g. the kernel checks
> > > CAP_DAC_OVERRIDE and falls back to CAP_DAC_READ_SEARCH if only
> > > read/search access was requested, and there are other cases where a
> > > permission denial has a side effect rather than preventing the system
> > > call (e.g. CAP_FSETID).
> > >
> > > On Wed, Apr 30, 2014 at 6:34 AM, Daniel J Walsh <dwalsh(a)redhat.com>
> >
> > wrote:
> > >> 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
> >
> > --
> > Linux-audit mailing list
> > Linux-audit(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit
11:20 a.m.
New subject: [RFC][PATCH] selinux: Report result in avc messages
Yes Stephen is correct. I was suggesting a change to the variable not to
the key in the output KVP.
However...Stephens patch would grow in size and he would have to type that
much more :-)
On Apr 30, 2014 9:08 AM, "Stephen Smalley" <stephen.smalley(a)gmail.com>
wrote:
The revised patch switched from result=allowed|denied to
permissive=0|1 in the avc message. I think Bill's point was with
respect to the code, which still internally is passing around the
result of the decision and inferring the permissive state from it,
rather than the output string itself.
On Wed, Apr 30, 2014 at 9:01 AM, Steve Grubb <sgrubb(a)redhat.com> wrote:
> On Wednesday, April 30, 2014 08:48:31 AM William Roberts wrote:
>> My only nit would be the variable name result....would it be better
named
>> is_permissive or something?
>
> That adds more bytes. My personal taste would be to abbreviate it to save
> bytes. They add up when you have 100's of thousands of events per day.
>
> -Steve
>
>
>> Otherwise LGTM. From the Android camp, this will be very helpful.
>> On Apr 30, 2014 8:43 AM, "Stephen Smalley"
<stephen.smalley(a)gmail.com>
>>
>> wrote:
>> > Attached patch switches to reporting permissive=0|1 and only does it
>> > for avc: denied messages.
>> >
>> > On Wed, Apr 30, 2014 at 8:18 AM, Stephen Smalley
>> >
>> > <stephen.smalley(a)gmail.com> wrote:
>> > > I could make it permissive=0 or permissive=1 if that is less
>> > > confusing. It doesn't necessarily correspond to the result of
the
>> > > system call, just the avc_has_perm call, as e.g. the kernel checks
>> > > CAP_DAC_OVERRIDE and falls back to CAP_DAC_READ_SEARCH if only
>> > > read/search access was requested, and there are other cases where a
>> > > permission denial has a side effect rather than preventing the
system
>> > > call (e.g. CAP_FSETID).
>> > >
>> > > On Wed, Apr 30, 2014 at 6:34 AM, Daniel J Walsh
<dwalsh(a)redhat.com>
>> >
>> > wrote:
>> > >> 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
>> >
>> > --
>> > Linux-audit mailing list
>> > Linux-audit(a)redhat.com
>> > https://www.redhat.com/mailman/listinfo/linux-audit
>
2:09 p.m.
New subject: [RFC][PATCH] selinux: Report result in avc messages
On Wednesday, April 30, 2014 09:08:28 AM Stephen Smalley wrote:
The revised patch switched from result=allowed|denied to
permissive=0|1 in the avc message. I think Bill's point was with
respect to the code, which still internally is passing around the
result of the decision and inferring the permissive state from it,
rather than the output string itself.
I'm fine with this patch, but before I merge it for next I just wanted to make
sure there isn't another revision coming?
--
paul moore
www.paul-moore.com
3:11 p.m.
New subject: [RFC][PATCH] selinux: Report result in avc messages
I'm fine with it as is.
On Thu, May 1, 2014 at 12:09 PM, Paul Moore <paul(a)paul-moore.com> wrote:
On Wednesday, April 30, 2014 09:08:28 AM Stephen Smalley wrote:
> The revised patch switched from result=allowed|denied to
> permissive=0|1 in the avc message. I think Bill's point was with
> respect to the code, which still internally is passing around the
> result of the decision and inferring the permissive state from it,
> rather than the output string itself.
I'm fine with this patch, but before I merge it for next I just wanted to make
sure there isn't another revision coming?
--
paul moore
www.paul-moore.com
2:47 p.m.
New subject: [RFC][PATCH] selinux: Report result in avc messages
On Thursday, May 01, 2014 01:11:57 PM Stephen Smalley wrote:
I'm fine with it as is.
Okay, it's applied to the next branch.
On Thu, May 1, 2014 at 12:09 PM, Paul Moore
<paul(a)paul-moore.com> wrote:
> On Wednesday, April 30, 2014 09:08:28 AM Stephen Smalley wrote:
>> The revised patch switched from result=allowed|denied to
>> permissive=0|1 in the avc message. I think Bill's point was with
>> respect to the code, which still internally is passing around the
>> result of the decision and inferring the permissive state from it,
>> rather than the output string itself.
>
> I'm fine with this patch, but before I merge it for next I just wanted to
> make sure there isn't another revision coming?
>
> --
> paul moore
> www.paul-moore.com
--
paul moore
www.paul-moore.com
10:52 a.m.
New subject: [RFC][PATCH] selinux: Report result in avc messages
Acked-by: Eric Paris <eparis(a)redhat.com>
On Wed, 2014-04-30 at 08:38 -0700, Stephen Smalley wrote:
Attached patch switches to reporting permissive=0|1 and only does it
for avc: denied messages.
On Wed, Apr 30, 2014 at 8:18 AM, Stephen Smalley
<stephen.smalley(a)gmail.com> wrote:
> I could make it permissive=0 or permissive=1 if that is less
> confusing. It doesn't necessarily correspond to the result of the
> system call, just the avc_has_perm call, as e.g. the kernel checks
> CAP_DAC_OVERRIDE and falls back to CAP_DAC_READ_SEARCH if only
> read/search access was requested, and there are other cases where a
> permission denial has a side effect rather than preventing the system
> call (e.g. CAP_FSETID).
>
> On Wed, Apr 30, 2014 at 6:34 AM, Daniel J Walsh <dwalsh(a)redhat.com> wrote:
>>
>> 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
>>
4200
days inactive
4202
days old
linux-audit@lists.linux-audit.osci.io
13 comments
6 participants
participants (6)
-
Daniel J Walsh -
Eric Paris -
Paul Moore -
Stephen Smalley -
Steve Grubb -
William Roberts