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.
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
http://www.tresys.com | oss.tresys.com
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
http://www.tresys.com | oss.tresys.com
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
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
http://www.tresys.com | oss.tresys.com