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.
> 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.
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.
>
> 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).
--
Jamie Strandboge | http://www.canonical.com
signature.asc
Description: This is a digitally signed message part
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
