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

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

[Paul Howarth]

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.

[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

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

[Christopher J. PeBenito]

On 09/14/11 10:23, Christopher J. PeBenito wrote:
> On 09/12/11 10:37, Paul Howarth wrote:
>> 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.
 
This ended up being straightforward.  I updated corenetwork so that it supports defining a port type without labeling any specific ports.  That'll get the interfaces generated so we can write policy correctly (look at the contrib commit if you're not sure what I mean).

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

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

[Paul Howarth]

On 09/14/2011 05:27 PM, Christopher J. PeBenito wrote:
> On 09/14/11 10:23, Christopher J. PeBenito wrote:
>> On 09/12/11 10:37, Paul Howarth wrote:
>>> 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.
>
> This ended up being straightforward.  I updated corenetwork so that it supports defining a port type without labeling any specific ports.  That'll get the interfaces generated so we can write policy correctly (look at the contrib commit if you're not sure what I mean).

OK, here's two patches, one for corenetwork to add milter_port_t, and 
another for milter to use milter_port_t.

Paul.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-milter_port_t.patch
Type: text/x-patch
Size: 1089 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110915/e728b2dd/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Allow-communication-with-MTA-over-a-TCP-socket.patch
Type: text/x-patch
Size: 1105 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110915/e728b2dd/attachment-0001.bin 

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

[Christopher J. PeBenito]

On 09/15/11 10:17, Paul Howarth wrote:
> On 09/14/2011 05:27 PM, Christopher J. PeBenito wrote:
>> On 09/14/11 10:23, Christopher J. PeBenito wrote:
>>> On 09/12/11 10:37, Paul Howarth wrote:
>>>> 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.
>>
>> This ended up being straightforward.  I updated corenetwork so that it supports defining a port type without labeling any specific ports.  That'll get the interfaces generated so we can write policy correctly (look at the contrib commit if you're not sure what I mean).
> 
> OK, here's two patches, one for corenetwork to add milter_port_t, and another for milter to use milter_port_t.

Merged.

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