From: dwalsh@redhat.com (Daniel J Walsh) Date: Wed, 01 Oct 2008 08:31:52 -0400 Subject: [refpolicy] services_amavis.patch In-Reply-To: <48E35C62.8030609@martinorr.name> References: <48DAA876.2030804@redhat.com> <200809251719.10269.russell@coker.com.au> <48DB81B6.6060906@martinorr.name> <200809271042.26493.russell@coker.com.au> <48E35C62.8030609@martinorr.name> Message-ID: <48E36DB8.80609@redhat.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Orr wrote: > On 27/09/08 01:42, Russell Coker wrote: >> On Thursday 25 September 2008 22:19, Martin Orr wrote: >>>> The CentOS servers that I run have Amavis and ClamAV running unconfined >>>> because getting the policy to work was too difficult (the two daemons >>>> interact with each other a lot, trying to keep them separate is a lost >>>> cause). >>> How do they interact with each other beyond communicating by a socket and >>> clamd reading amavis spool files? >> They can communicate by a socket or by running a program. > > Doesn't seem like interacting a lot to me. > > But I've thought a bit more about why I dislike merging the amavis and > clamav domains, and my primary concern is that it is confusing to have > amavisd running as clamav_t. If I saw a denial with > comm="amavisd" scontext=system_u:system_r:clamav_t:s0 > then I would assume that there was a missing transition somewhere. > > For similar reasons I dislike the fact that wpa_supplicant runs as > NetworkManager_t, and the MTA policy is full of confusingly named types and > attributes, but that's no reason to introduce another one. > > So while I still don't see the value of merging amavis_t and clamav_t when > separate policy has already been written, I would be a lot happier if the > merged domain were not called clamav_t. > > Best wishes, > mailscanner_t perhaps? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkjjbbcACgkQrlYvE4MpobPvkgCfX+KEfAuZXhgzD9aRozZgyuWR 9hkAn0rSeI+6xIzyIbNN58EvkXifDZel =mIhq -----END PGP SIGNATURE-----