[refpolicy] Best approach for adding inet socket support for milters?

[Christopher J. PeBenito]

On 09/12/11 10:37, Paul Howarth wrote:
> I'd like to revisit adding TCP/inet socket support for milters. In my 
> original submission of the milter policy, I had a milter_port_t but 
> didn't assign any port numbers to the type, as there's no well-known 
> standard port for this functionality, with sysadmins expected to 
> allocate a spare port of their own choice for this purpose. This 
> approach was based on the stunnel policy, which has a similar requirement.
> 
> The milter_port_t never made it into refpolicy so currently milters 
> based on the milter template are restricted to using unix domain sockets 
> in the absence of local policy for inet sockets.
> 
> This is a problem for a couple of reasons:
> 
> 1. Much documentation for milters includes instructions for 
> configuration using inet sockets rather than unix domain dockets; anyone 
> following those instructions will have SELinux problems when using 
> milters supported by refpolicy.
> 
> 2. The Postfix MTA uses a different security model than sendmail, and is 
> set up to connect to milters using group writeable unix sockets. 
> However, sendmail considers group writeable unix sockets to be "unsafe" 
> and won't use them by default. So it's difficult to specify an "out of 
> the box" milter configuration that supports both MTAs using unix domain 
> sockets, so the Postfix milter users are more inclined to use inet sockets.
[...]
> I'd rather return to my original suggestion of having a milter_port_t be 
> supported out of the box and then let admins use semanage to define any 
> ports they wanted to use as milter_port_t.

This is fine.  I can't remember if I originally rejected this (I'm guessing I did), but I'm fine with it now.  We already have examples of this, eg, stunnel.  We should look into augmenting the corenetwork infrastructure so that the network_port() macro can handle no defined ports, so that interfaces for the type will be created.  I believe this already works for the interface generation, but the te side needs to be tweaked to not emit an incomplete portcon statement.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com