From: martin@martinorr.name (Martin Orr) Date: Wed, 01 Oct 2008 12:17:54 +0100 Subject: [refpolicy] services_amavis.patch In-Reply-To: <200809271042.26493.russell@coker.com.au> References: <48DAA876.2030804@redhat.com> <200809251719.10269.russell@coker.com.au> <48DB81B6.6060906@martinorr.name> <200809271042.26493.russell@coker.com.au> Message-ID: <48E35C62.8030609@martinorr.name> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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, -- Martin Orr