[apparmor] Logging of actions that are already denied by the filesystem

[John Johansen]

On 03/31/2011 02:38 PM, Christian Boltz wrote:
> Hello,
> 
> Am Donnerstag, 31. März 2011 schrieb John Johansen:
>> On 03/31/2011 11:06 AM, Christian Boltz wrote:
>>> Amavisd tries to rename /etc/amavisd.conf to *.moved at startup to
>>> check if dropping privileges worked.
>>> Amavisd runs as user "vscan" at this point 
> 
>>> Nevertheless, I see in the audit.log:
> ...
>>> IIRC older AppArmor versions (for example on openSUSE 11.1 - which
>>> interestingly also has AppArmor 2.3...) only logged actions that
>>> were permitted by the filesystem. Did this change or did I find a
>>> bug? ;-)
>>
>> Sadly it changed.  AppArmor 2.3 used a different set of hooks
>> (patched the existing inode hooks), but upstream accepted a new set
>> of path hooks, that are inserted at different points.
> 
> Hmm, openSUSE 11.1 and 11.3 both use AppArmor 2.3 - is there really such 
> a big difference? (The kernel version of course differs.)
> 
Its the kernel part that differs, and the difference is huge.  It was almost
a complete rewrite between the new path hooks and creds.  We tried really
hard to maintain the same semantics but there was a few places that we
just couldn't make it 100% the same.

>> It is now inconsistent as to whether the DAC check or MAC check comes
>> first for some hooks DAC for others using the path hooks MAC.  There
>> was effort to fix this but it didn't get in.
> 
> Sounds very interesting[tm]. 
> I hope someone still tries to get this fixed ;-)
> 
well I can take a stab at it, TOMOYO tried last time but the response
last time was less than promising.

>>> (Needless to say that I have a "deny /etc/amavisd.conf* w" rule in
>>> the meantime to silence the logging...)
>>
>> yep, its unfortunate but we have to live with it
> 
> Does this also happen with AppArmor 2.5? (Until now, I don't have a 
> server with 2.5 running, therefore it isn't easy to test for me.)
> 
yes.  Well the actually answer is it depends on your kernel.  Anything
2.6.31 or newer has this behavior.

>>> If something in this mail is unclear, I can re-test it. Just notice
>>> that the above information is recycled from a (non-public) bug
>>> report that was sleeping for some weeks...
>>
>> ah, sorry to hear that.  I can put together a more detailed report if
>> needed with links to the lkml discussions.
> 
> Your short summary is enough :-) - better invest the time to get this 
> fixed in the kernel... (Now you can at least add a paragraph "We already 
> get complaints from confused users." ;-)
> 
hehe, yes.  And it is also something we should put in the wiki that we
can point to.