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

[John Johansen]

On 03/31/2011 11:06 AM, Christian Boltz wrote:
> Hello,
> 
> I have an interesting finding on an openSUSE 11.3 system which I first 
> thought to be a bug in Amavisd failing to drop privileges, but I just 
> verified that Amavisd is working correctly.
> 
> 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 (I verified this by creating 
> a test file in /tmp) and therefore does not have filesystem write 
> permissions in /etc (/etc and /etc/amavisd.conf are owned by root and 
> don't have write permissions for group or others - also checked.)
> In other words: Amavisd already gets a "permission denied" from the 
> filesystem level.
>  
> Nevertheless, I see in the audit.log:
> 
> operation="rename_src" pid=8522 parent=8520 profile="/usr/sbin/amavisd"
> requested_mask="::w" denied_mask="::w" fsuid=65 ouid=0 
> name="/etc/amavisd.conf"
> 
> operation="rename_dest" pid=8522 parent=8520 profile="/usr/sbin/amavisd"
> requested_mask="::w" denied_mask="::w" fsuid=65 ouid=0
> name="/etc/amavisd.conf.moved"
> 
yep

> or translated to rules
>     /etc/amavisd.conf rw,              # read + write
>     /etc/amavisd.conf.moved w,         # write only
> 
> 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.

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.

> (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

> 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.