From mboxrd@z Thu Jan 1 00:00:00 1970 From: paul@city-fan.org (Paul Howarth) Date: Thu, 06 Nov 2008 15:24:07 +0000 Subject: [refpolicy] Milter Mail Filters In-Reply-To: <1225984176.12285.15.camel@gorn.columbia.tresys.com> 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> <1225984176.12285.15.camel@gorn.columbia.tresys.com> Message-ID: <49130C17.8050208@city-fan.org> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com Christopher J. PeBenito wrote: > On Fri, 2008-10-10 at 19:24 +0100, Paul Howarth wrote: >> On Wed, 8 Oct 2008 15:22:25 -0400 >> "Christopher J. PeBenito" 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. It's not a case of one milter needing it and another not needing it; potentially any milter can be used in conjunction with TCP ports. The usual convention is to use a unix domain socket for communication between a milter and the MTA but the milter library supports both approaches, and some sysadmins may wish to configure their milters to use TCP sockets, so that for instance they can run the milters on separate hosts from the MTA in order to spread load. When they do this, each milter will need support in policy, which is why I included it in the template. Paul.