[apparmor] new rule qualifier "quiet" or "noaudit"

[John Johansen]

On 05/23/2018 03:15 PM, Jamie Strandboge wrote:
> On Mon, 2018-04-02 at 15:48 -0700, John Johansen wrote:
>> Current apparmor has the ability to selectively quiet audit denials
>> at
>> the rule level but only when the "deny" rule qualifier is used. We
>> would like to make the ability to quiet auditing at the rule level
>> available without the associated semantics of deny, which means
>> extending the language with a new keyword. This is a feature that can
>> be added with only changes to the userspace, and could also be a
>> profile flag, by directly the compiler to set it on every rule when
>> the flag is present.
>>
> Sorry for only responding to this now (I've had it on my TODO to give
> some thought for a while now!) and thank you for putting this together.
> :)
> 
>> Currently /sys/module/apparmor/parameters/audit supports the
>> following
>>
>> "normal" - don't modify auditing from the profile. This option does
>>            not make sense at the rule or profile level
>>
>> "quiet_denied" - quiet denials.  Similar to quiet by does to override
>>                  the audit keyword
>>
>> "quiet" - quiet all logging.     Over rides audit
>>
>> "noquiet - do not apply rule or profile quieting.  Turns off quiet
>>            keyword, I am not sure this makes sense at a rule level
>> but
>>            certainly does at the profile level.
>>
>> "all" - force every event to audit.  Is equivalent to the current
>>         profile audit flag
>>
>>
>> All of these can actually be implemented today, though when used as a
>> profile flag will actually have to be carried at the rule level, so
>> no
>> ability to change the profile at run time by toggling a profile flag
>> (when that ability lands).
> 
> I'm reading this as 'quite/noaudit/whatever' rules can be implemented
> today and that implementing the corresponding profile flag will come
> later. The ability to turn off auditing at the profile level (ie, using
> a profile flag) actually came up recently as something that would be
> convenient.
> 
right quiet could be enabled today. It only requires changes in the
parser. A profile level flag could also be implemented by having
it implicitly apply quite/noaudit to every rule.

> 
>> Please vote for
>>
>> 1) quiet.
>>
>>   quiet w /foo/bar/**,
>>
>> 2) noaudit
>>
>>   noaudit w /foo/bar/**,
>>
>> 3) other
>>
>>   please leave your suggestion.
>>
> 
> noaudit has a nice symmetry with 'audit', but 'quiet' works better with
> the allowed values for /sys/module/apparmor/parameters/audit. That
> said, 'noaudit' is not actually the counterpart for 'audit' if we
> consider the following 'audit' examples:
> 
> audit w /foo/bar/**,    # allow and audit
> audit deny /foo/bar/**, # explicitly deny and audit
> 
> then if we used 'noaudit' a profiler might expect to be able to do:
> 
> noaudit w /foo/bar/**,    # allow and no auditing
> noaudit deny /foo/bar/**, # explicitly deny and no auditing
> 
> but these rules don't make any sense since 'allow' and 'deny' already
> don't audit.
> 
hrmmm, I wouldn't say they make no sense, They would be redundant but
provide language symmetry and some times people like to get specific.

Eg.
  allow w /foo/bar/**,

for language symmetry it may be worth considering adding

> Therefore, I prefer 'quiet' since it is not a modifier for an
> allow/deny rule; it is instead a new rule whose only purpose is to
> provide fine-grained quieting with no effect on mediation.
> 
This is the behavior that is desired, but thinking about it more
I don't like it as a new rule type instead of a modifier. Its a
behavior I have wanted at times with audit as well.

What about a new keyword in the place of allow/deny so that
we could specify that the rule is not specifying an allow or
a deny but is to be applied to all access attempts that it
overlaps

audit access w /foo/bar/**,
quiet access w /foo/bar/**,

this would allow audit to continue to be used as a modifier,
and also then allow quiet to be used as a modifier for the
sake of symmetry of the language.

> 
>>
>> At the same time we should determine how it will be used as a profile
>> flag
>>
>> A) the keyword by it self
>>
>>   profile foo flags=(quiet) { ... }
>>   profile foo flags=(noaudit) { ... }
>>
>> B) the keyword as a modifier to the audit flag
>>
>>   profile foo flags=(audit=quiet) { ... }
>>   profile foo flags=(audit=noaudit) { ... }
> 
> I prefer 'A' with 'flags=(quiet)' to work in congruence with the
> 'quiet' rule I voted for above.
> 
> As for 'B', we don't have many profile modifiers today, so breaking out
> 'audit=...' to carve out a separate area for audit flags seems
> premature (though if people felt strongly about 'flags=(audit=quiet)' I
> wouldn't object).
> 

I tend to agree, thanks