From: paul@city-fan.org (Paul Howarth)
Date: Mon, 12 Sep 2011 15:37:39 +0100
Subject: [refpolicy] Best approach for adding inet socket support for
	milters?
Message-ID: <4E6E1933.1030100@city-fan.org>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

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.

So what I'd like to know is what is the best approach to having inet 
socket support for milters in refpolicy?

If I run a milter with inet sockets in permissive mode and run the AVCs 
through audit2allow -R, I get something like:

corenet_tcp_bind_generic_port(foo_milter_t)
corenet_tcp_connect_generic_port(foo_milter_t)
allow foo_milter_t self:tcp_socket { accept listen };

That would allow milters to connect to any port, which I don't think is 
good, even with a boolean to prevent this being the default policy. 
However, the clamav policy (not based on the milter template) seems to 
use this approach.

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.

Or is there a better approach that I've not though of?

Paul.