From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Mon, 06 Oct 2008 14:28:27 -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: <1223317707.2165.42.camel@gorn> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On Wed, 2008-10-01 at 12:17 +0100, 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. I'd tend to agree with this. > 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. Getting the right granularity for the upstream policy is an ongoing struggle. I've heard others complain about this particular one too. > 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. I'm not so convinced about a merged policy, but I'm open to new ideas. I'd have to see patches. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150