Am Montag, 25. April 2016, 14:38:58 CEST schrieb Carlos E. R.:
> On 2016-04-25 01:04, Christian Boltz wrote:
> > Can you check if you still get dovecot-related events in
> > /var/log/audit/audit.log? (tail -f while restarting and using
> > dovecot) If in doubt, paste the log lines in your next mail or on
> > paste.opensuse.org (if it's more than 20 lines).

Those lines are normal and have nothing to do with AppArmor.
(Lines that have to do with AppArmor include "apparmor" somewhere, and 
in most cases also include ALLOWED or DENIED.)

> > Also try to (temporarily) remove the vsz_limit and default_vsz_limit
> > settings in your dovecot config to see if they are causing this
> > problem.
> The entries in the audit log change a little:

Also nothing related to AppArmor.

> > BTW:
> >> In fact, the change has been applied to
> >> 
> >> /etc/apparmor.d/usr.sbin.dovecot several times:
> >>  capability           setuid,
> >>  
> >>   capability           sys_chroot,
> >>   capability       sys_resource,
> >>   capability      sys_resource,
> >>   capability     sys_resource,
> >>   capability    sys_resource,
> >>   capability   sys_resource,
> >>   capability  sys_resource,
> >>   capability sys_resource,
> > 
> > *lol*
> > 
> > I know the 2.8.x AppArmor tools have quite some bugs (that's one of
> > the reasons why they were rewritten in python for 2.9), but I'm not
> > sure if I have ever seen this one.
> > Anyway, the profile clearly allows the sys_resource capability ;-))
> > (having 10 similar lines for it doesn't hurt)
> The problem is that when I run aa-logprof, I always get:
> Telcontar:~ # aa-logprof
> Reading log entries from /var/log/audit/audit.log.
> Updating AppArmor profiles in /etc/apparmor.d.
> Enforce-mode changes:
> Profile:    /usr/sbin/dovecot
> Capability: sys_resource
> Severity:   8
> (A)llow / [(D)eny] / Audi(t) / Abo(r)t / (F)inish
> Maybe I have something set to "audit" and I forgot :-?

aa-logprof will read the log again every time you run it, which means it 
sees the "old" event again.

I just checked the perl code. Besides being reminded why we wanted to 
get rid of that ;-) I can probably explain what happens.

This is from the code that parses the profile in /etc/apparmor.d:

        } elsif 
(m/^\s*(audit\s+)?(deny\s+)?capability(\s+(\S+))?\s*,\s*(#.*)?$/) {  # 
capability entry
            # [...]
            my $capability = $3 ? $3 : 'all';

If you start counting parenthesis, you'll notice that $1 is audit, $2 
is deny and $3 is everything between the 'capability' keyword and the 
comma. __Including the spaces!__ ($4 would be without spaces.)

So aa-logprof knows the profile already contains the "   sys_resource" 
(including the spaces!) capability, but the log tells it about the 
"sys_resource" capability (without spaces), which is technically a 
different one ;-)

And to make things even more funny, a space gets added every time the
profile gets written, which explains why your profile looks like stairs ;-)

I don't want to change the old perl code unless _really_ necessary 
because I'm not sure what changing this would possibly break - living 
with this funny and slightly annoying bug sounds like the safer option 
to me [1].

To get rid of the repeated questions, rotate the old audit.log away:
    old /var/log/audit/audit.log   # will rename it to audit.log-$date
    rcauditd restart


Christian Boltz

[1] I'd even argue that replacing the aa-* perl tools with the 2.10.1
    python tools is less risky than changing anything in the perl code!

The attack is standards-compliant and compatible with all vendors
and drivers. ["802.11 Packets in Packets" abstract,

Evergreen mailing list

Reply via email to