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

Steve Beattie steve at nxnw.org
Wed Jun 25 17:58:16 UTC 2014


On Wed, Jun 25, 2014 at 01:51:44PM +0200, Christian Boltz wrote:
> 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.

Okay. I'll prepare patches to do the move and fixup the postfix profiles
to compensate.

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

This is the contents of /var/spool/postfix/etc/ on the ubuntu 14.04
server that I'm updating these profiles on:

  -rw-r--r-- 1 root root  4462 Jun 24 12:10 hosts
  -rw-r--r-- 1 root root  2819 Jun 24 12:10 localtime
  -rw-r--r-- 1 root root   475 Jun 24 12:10 nsswitch.conf
  -rw-r--r-- 1 root root   188 Jun 24 12:10 resolv.conf
  -rw-r--r-- 1 root root 19558 Jun 24 12:10 services
  drwxr-xr-x 3 root root  4096 Nov  9  2013 ssl

(and yes, the rule above doesn't grant access to stuff below ssl/, by
default, which happens to be just ca-certificates.crt.)  That said,
I don't use sasl or anything like that, so that may be why I don't
have a postfix/ subdirectory there? But then, see your comment about
sasl db files not needing to be in the chroot.

> - but that would also be broader than what we allow in the non-chrooted
> /etc.

Right.

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

Agreed. Note that the accesses to *.cf and *.db in /etc/postfix/ are
already present in postfix-common. Even more annoying is an issue
raised on the debian apparmor profile packaging list: custom pcre
regex files (see pcre_table(5)) which don't have a (standardized)
suffix, are not compiled into a db file, and for custom files, don't
have a common naming scheme.

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

Right. I don't really have a good solution for this that doesn't
involve encouraging people to use specific names/subdirectories for
sensitive bits of postfix configuration that shouldn't be shared
amongst all the postfix processes.

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

I would assume that the postfix binaries would already include
abstractions/base, which would cover /lib and /lib/@{multiarch},
so I don't think the additional reading complexity of a regex gains
you anything. But that may be just me.

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

Yes, this is what I'm trying to do, too. :)

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

Probably. I hadn't actually realized that the dovecot profiles had
been moved to the active profile set; in Ubuntu, we're setting them to
complain mode by default in an effort not to break users, so we could
either do that upstream for postfix or let distros decide to do that
(see some of the above issues as to why).

> Regards,

Thanks for the feedback.

-- 
Steve Beattie
<sbeattie at ubuntu.com>
http://NxNW.org/~steve/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20140625/fc701d77/attachment.pgp>


More information about the AppArmor mailing list