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. <div class="gmail_quote">On Apr 30, 2014 8:43 AM, "Stephen Smalley" <<a href="mailto:stephen.smalley@gmail.com">stephen.smalley@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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 <<a href="mailto:stephen.smalley@gmail.com">stephen.smalley@gmail.com</a>> 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 <<a href="mailto:dwalsh@redhat.com">dwalsh@redhat.com</a>> 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 <a href="http://thesaurus.com" target="_blank">thesaurus.com</a>. :-) >>> >>> consequence, outcome, effect, reaction, conclusion, verdict, decision, >>> judgement, finding, ruling, answer, solution, recommendation, order, ... >>> >>> -Steve >> -- Linux-audit mailing list <a href="mailto:Linux-audit@redhat.com">Linux-audit@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/linux-audit" target="_blank">https://www.redhat.com/mailman/listinfo/linux-audit</a> </blockquote></div>