[apparmor] [patch] profiles: update postfix-common

Christian Boltz apparmor at cboltz.de
Wed Jun 25 11:51:44 UTC 2014


Hello,

Am Dienstag, 24. Juni 2014 schrieb Steve Beattie:
> Attached is a patch that updates postfix-common to take into account
> of some multiarch stuff, some chrooting that postfix does, and that
> the postfix master process sends signals to all the different utility
> processes.
> 
> As a followup, I'd like to move postfix-common from program-chunks
> directory (and kill the directory), as it is the last remaining
> vestigial file there (the rest having been moved out in 2007!),
> and place it into the abstractions/ directory, where it would

Good idea.

> serve a similar role as the apache2-common abstraction as well as a
> dovecot-common abstraction I have in the pipeline.

Also sounds good ;-)

> Signed-off-by: Steve Beattie <steve at nxnw.org>
> ---
>  profiles/apparmor.d/program-chunks/postfix-common |   17
> +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-)
> 
> Index: b/profiles/apparmor.d/program-chunks/postfix-common
> ===================================================================
> --- a/profiles/apparmor.d/program-chunks/postfix-common
> +++ b/profiles/apparmor.d/program-chunks/postfix-common
> @@ -1,6 +1,7 @@
>  # ------------------------------------------------------------------
>  #
>  #    Copyright (C) 2002-2005 Novell/SUSE
> +#    Copyright (C) 2014 Canonical, Ltd.
>  #
>  #    This program is free software; you can redistribute it and/or
>  #    modify it under the terms of version 2 of the GNU General Public
> @@ -14,11 +15,19 @@
>    capability            setgid,
>    capability            sys_chroot,
> 
> +  # postfix's master can send us signals
> +  signal receive peer=/usr/lib/postfix/master,
> +
> +  /etc/mailname         r,
>    /etc/postfix/*.cf     r,
>    /etc/postfix/*.db     r,
>    @{PROC}/net/if_inet6  r,
>    /usr/lib/postfix/*.so mr,
> -  /usr/lib64/sasl2/*    mr,
> -  /usr/lib64/sasl2/     r,
> -  /usr/lib/sasl2/*      mr,
> -  /usr/lib/sasl2/       r,
> +  /usr/lib{,32,64}/sasl2/*    mr,
> +  /usr/lib{,32,64}/sasl2/     r,
> +  /usr/lib/@{multiarch}/sasl2/*      mr,
> +  /usr/lib/@{multiarch}/sasl2/       r,
> +
> +  /var/spool/postfix/etc/*        r,

I doubt this is useful - to make it useful, $chroot/etc/** would be 
needed (with just *, reading $chroot/etc/postfix/* is impossible) - but 
that would also be broader than what we allow in the non-chrooted /etc.

That said: not all postfix binaries need read access to all files in 
/etc/postfix - but I'm not sure if it's worth the effort to add detailed 
restrictions or if detailed restrictions just annoy the users because 
they have to update the profile for every little change/new config file.

The only critical file is probably /etc/postfix/sasl-passwd{,.db} which 
contains passwords if postfix is sending mails to a smarthost with SMTP 
auth. The filename is of course configureable (smtp_sasl_password_maps) 
[1] which means we can't rely on the filename.


Another interesting question is if we should simply keep chroot and non-
chroot in sync by using /{var/spool/postfix/,}etc/$whatever

> +  /var/spool/postfix/lib/lib*.so* mr,
> +  /var/spool/postfix/lib/@{multiarch}/lib*.so* mr,

Same question as above - what about /{var/spool/postfix/,}lib ?


That all reminds me that I have updated postfix profiles on my servers - 
I should probably collect and merge them and then submit patches ;-)
(but not this week ;-)


BTW: Currently, all postfix profiles are in extra (inactive). Should we 
move them to the set of active profiles after updating them?


Regards,

Christian Boltz

[1] While we are talking about it: postconf(5) says about it:
        The Postfix SMTP client opens the lookup table before going to
        chroot jail, so you can leave the password file in /etc/postfix.

-- 
Schlagen. Verklagen. Z.B. bei der c't verpfeifen, auf daß es fortan
die Spatzen von den Dächern pfeifen, was für Pfeifen das bei $Firma
sind. *scnr* [David Haller in suse-linux]




More information about the AppArmor mailing list