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

[Christian Boltz]

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"

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? ;-)

(Needless to say that I have a "deny /etc/amavisd.conf* w" rule in the 
meantime to silence the logging...)

If something in this mail is unclear, I can re-test it. Just notice that 
the above information is recycled from a (non-public) bugreport that was 
sleeping for some weeks...


Regards,

Christian Boltz
-- 
What do we learn from this: DO NOT use reiser4 with Suse Linux 10.0.
Shred and wipe offer easier ways to get rid of your data.
[nordi in opensuse]