Mailman/Postfix execute_no_trans denial

[Todd Zullinger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Howarth wrote:
> On Mon, 2006-05-22 at 20:17 -0400, Todd Zullinger wrote:
>> May 22 20:06:36 localhost kernel: audit(1148342796.578:36): avc:  denied  { search } for  pid=9382 comm="python" name="log" dev=sda2 ino=489147 scontext=user_u:system_r:postfix_local_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=dir
> 
> Looks like mailman trying to read the log file directory. May need a
> policy change for this - I needed something similar for procmail.

Could you point me toward the policy change you had to make for
procmail?  The inode referred to is indeed /var/log.  Since mailman is
patched by RH/Fedora to use /var/log/mailman I imagine that being able
to read the log dir should be allowed or if mailman is trying to read
more than it needs to read that should then be patched in the
RH/Fedora mailman package.

>> May 22 20:06:36 localhost kernel: audit(1148342796.582:37): avc:  denied  { write } for  pid=9382 comm="python" name="in" dev=sda2 ino=491751 scontext=user_u:system_r:postfix_local_t:s0 tcontext=user_u:object_r:mailman_data_t:s0 tclass=dir
> 
> Failed trying to write new file to directory /var/spool/mailman/in.
> 
> I wonder if the mailman policy was written specifically with sendmail in
> mind rather than postfix?

That's certainly possible, but the denials in reading the log dir and
writing to /var/spool/mailman/in would seem to be problems even when
used with sendmail.  If I get some time I will re-install sendmail on
this system and see how well the mailman policy fares there.  (That'll
be a first for me, intentionally installing sendmail. :)

It's odd too, as most (if not all?) the redhat.com lists use mailman
and postfix.  So I would have guessed the combination would have been
tested more.  It sure seems to be non-functional with SELinux enabled.
Hopefully with a little testing here the policy can get updated.  I
imagine Dan Walsh has his hands full for quite a while after a new FC
release.

>> I'm not sure whether it's worth trying to chase every denial down
>> this path or if there is a better fix that can be applied.
> 
> I'm not sure. Running in permissive mode for a while should show up
> all the denials you'll come across, but they might not all need
> allowing, and if something has the wrong label, as appears to be the
> case with /usr/lib/mailman/mail/mailman, then the denials won't be
> useful anyway.

That makes sense.  Thanks for the info Paul.

I don't have any need to roll out mailman with SELinux on any
production boxes, so I'm in no great hurry.  I just figured that since
I was testing mailman and FC5 I'd try to help work out the SELinux
issues as well.

There's a bugzilla entry for mailman and postfix, but it dealt with a
different method for integrating mailman and postfix using an external
script.  I'm not sure why in the bug this is referred to as "the most
common method of postfix/mailman integration" as I would think the
built in Postfix integration is more common. :)

- -- 
Todd        OpenPGP -> KeyID: 0xD654075A | URL: www.pobox.com/~tmz/pgp
======================================================================
The state is the great fictitious entity by which everyone seeks to
live at the expense of everyone else.
    -- Fredric Bastiat

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: When crypto is outlawed bayl bhgynjf jvyy unir cevinpl.

iG0EARECAC0FAkR0AJEmGGh0dHA6Ly93d3cucG9ib3guY29tL350bXovcGdwL3Rt
ei5hc2MACgkQuv+09NZUB1qX1QCcCrRI8cI3jgQh2XyC/gulXmLA/LkAn09EEh90
D80Cdt8lEJbHfRIbMdhC
=eUFv
-----END PGP SIGNATURE-----