[refpolicy] services_amavis.patch

[cpebenito@tresys.com (Christopher J. PeBenito)]

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 <martin@martinorr.name> 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