[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [suse-security] [SLE] postfix and apparmour

Carlos E. R. wrote:
> I post this here so that the maintainer of apparmour sees it and corrects
> what I think are bugs.
Thank you! Yes, this is exactly what we need from users: discoveries of
how your use cases differ from ours, so that we can improve the profiles.

However, the apparmor-general list is more specific, and therefore more
appropriate, than the suse-security list, so I have posted to both and
directed followups to apparmor-general.

> When I installed 10.1 I had to add some rules to apparmour or postfix mail
> delivery with amavis would fail. These are my modifications I did then:
> ...
> I don't know if the correct procedure is to modify those files directly,
> but that's what I did and it works.
AppArmor does allow you to manually modify the profiles, and the syntax
was designed to make this easy to do.

However, the much, much easier way is to let AppArmor fix it for you. If
you grep for APPARMOR in /var/log/audit/audit.log you will find REJECT
events where AppArmor blocked the accesses that cause you problems. If
you run the "logprof" program (as root, and not confined by AppArmor) it
will inspect the audit.log file for events, and prompt you for what to
do with them. It will automatically expand your profiles to allow the
accesses that were blocked.

Note: logprof does not know the difference between an access that was
blocked because the profile was too tight, and an access blocked because
an intruder was trying to hack in. So if you are running logprof on a
machine exposed to the internet, please read the questions logprof asks
and thing about the answers :)

> Then I looked at /var/log/audit/audit.log, and sure, there was a problem:
> type=APPARMOR msg=audit(1153504846.751:1344): REJECTING r access to
> /var/spool/postfix/incoming/564677F01D (showq(18412) profile
> /usr/lib/postfix/showq active /usr/lib/postfix/showq)
Yes, like that :)

> So I go to /etc/apparmor.d/usr.lib.postfix.showq, and see this:
>   /{var/spool/postfix/,}incoming                                   r,
>   /{var/spool/postfix/,}incoming/[0-9A-F]                          r,
>   /{var/spool/postfix/,}incoming/[0-9A-F]/[0-9A-F]                 r,
>   /{var/spool/postfix/,}incoming/[0-9A-F]/[0-9A-F]/*               r,
>   /{var/spool/postfix/,}incoming/[0-9A-F]/[0-9A-F]*                r,
>   /{var/spool/postfix/,}incoming/[0-0A-F]*                         r,
> Now, the question: Should the last line be:
>   /{var/spool/postfix/,}incoming/[0-9A-F]*                         r,
> instead?

>    Notice that it is very dificult for me to test this: not till I get
>    another mail with certain ID will it work or fail.
You are right, that is a very subtle bug.

IMHO, it is because the profile we shipped was hand-tuned to be as tight
as possible, and the bug you found was a human-generated typo. It would
not have happened if the profile had been automatically generated by


Crispin Cowan, Ph.D.                      http://crispincowan.com/~crispin/
Director of Software Engineering, Novell  http://novell.com
     Hack: adroit engineering solution to an unanticipated problem
     Hacker: one who is adroit at pounding round pegs into square holes

Check the headers for your unsubscription address
For additional commands, e-mail: suse-security-help@xxxxxxxx
Security-related bug reports go to security@xxxxxxx, not here