From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Thu, 06 Nov 2008 10:09:36 -0500
Subject: [refpolicy] Milter Mail Filters
In-Reply-To: <20081010192409.0a76e299@metropolis.intra.city-fan.org>
References: <484D4B53.5020006@city-fan.org>
	<1216385922.21191.125.camel@gorn> <48982587.30605@city-fan.org>
	<1220621188.28287.79.camel@gorn.columbia.tresys.com>
	<48C6A124.7090707@city-fan.org> <48D78F39.3040801@city-fan.org>
	<1223302377.2165.5.camel@gorn> <48ECB037.2070203@city-fan.org>
	<1223493745.2165.113.camel@gorn.columbia.tresys.com>
	<20081010192409.0a76e299@metropolis.intra.city-fan.org>
Message-ID: <1225984176.12285.15.camel@gorn.columbia.tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Fri, 2008-10-10 at 19:24 +0100, Paul Howarth wrote:
> On Wed, 8 Oct 2008 15:22:25 -0400
> "Christopher J. PeBenito" <cpebenito@tresys.com> wrote:
> 
> > Moving to refpolicy list.
> > 
> > On Wed, 2008-10-08 at 14:05 +0100, Paul Howarth wrote:
> > > Christopher J. PeBenito wrote:
> > > > On Mon, 2008-09-22 at 13:27 +0100, Paul Howarth wrote:
> > > >> Updated patch: sendmail, when run as "newaliases", tries to
> > > >> getattr() milter sockets as well as the directories they live
> > > >> in, so I changed the 
> > > >> milter_getattr_all_data_dirs interface to
> > > >> milter_getattr_all_sockets.
> > > >>
> > > >> I also moved the call to this interface in mta.te out from the
> > > >> middle of 
> > > >> a bunch of postfix-related lines.
> > > >>
> > > >> Paul.
> > > > 
> > > > I think my last two comments are
> > > > 
> > > > * you can't require milter_port_t.  It doesn't seem like a
> > > > generic port type would be useful anyway, otherwise there would
> > > > be a port defined.
> > > 
> > > So I should change "allow milter_$1_t milter_port_t:tcp_socket 
> > > name_bind;" to "corenet_tcp_bind_generic_port($1_milter_t)"?
> > 
> > No.  I don't see how it makes sense to have a port type common to all
> > milters.
> > 
> > > I can do that but I don't understand why milter_port_t should be
> > > any different than say stunnel_port_t, which also doesn't have a
> > > default port defined, and would be used in a similar way, i.e. an
> > > admin would set up an application to use a specific port (a milter
> > > running over tcp needs to have a port specified, just a tunnel set
> > > up using stunnel does 
> > > - they don't just bind to random generic ports).
> > 
> > This is not comparable, as there is only one stunnel domain, whereas
> > there are several milter domains.
> 
> OK, I get that now, I'll use $1_milter_port_t instead then. But the 
> question then arises: how to interface to it? You say I can't require 
> milter_port_t and I guess that applies to $1_milter_port_t too.
> However, as there are no defined ports for these types, there's no
> expansion of network_port() for these types from corenetwork.te.in and
> hence no corenet_tcp_bind_$1_milter_port interface for me to call. I
> got the "require milter_port_t" idea from a similar structure in the
> stunnel policy.
> 
> How to proceed with this?

Sorry for the slow response; I've been consumed with the UBAC stuff.

I'd say don't declare the port in the template and we'll add ports as
milters require them.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150