[apparmor] audit and quiet rules

John Johansen john.johansen at canonical.com
Tue Jan 18 00:16:17 UTC 2011


On 01/14/2011 02:18 PM, Steve Beattie wrote:
> [Resurrecting an old thread]
> 
> On Wed, Dec 15, 2010 at 11:29:15PM -0800, John Johansen wrote:
>> On 12/15/2010 04:36 PM, Seth Arnold wrote:
>>> I immediately prefer audit_rules and quiet_rules versus our existing system. :)
>>
>> oh and I'm not very found of the keywords but audit seems to be taken, so suggestions
>> are more than welcome.
> 
> would something like:
> 
>   audit {
>     /** r,
>   }
> 
>   deny {
>     /etc/* w,
>   }
> 
> be more palatable.
> 
well I have been planning to add that once we get a few other cleanups to the front end
done.  The problem is they address different things.

The current audit rule syntax only addresses whole rules, and only rules that exist in
the current profile.  Looking at it now I think it was a mistake (but maybe that is just
me).

The proposed syntax allows specifying what you would liked audited, whether that exists
in the current profile or not.  It also allows for the audit expression to partially
overlap rules, making it so the policy author doesn't have to break apart rules to
get the same effect.

Admittedly I don't like having two different audit syntaxes, but to me it seems we need
some way to declaratively specify what should be audited without adding permissions.



More information about the AppArmor mailing list