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

Jamie Strandboge jamie at canonical.com
Wed May 23 22:15:46 UTC 2018


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20180523/39d776a9/attachment.sig>


More information about the AppArmor mailing list