Re: Iptables discussion

[Joshua Brindle <jbrindle@tresys.com>]

Daniel J Walsh wrote:

> Ivan Gyurdiev wrote:
>
>> On Mon, 2005-07-25 at 14:28 -0400, Ivan Gyurdiev wrote:
>>  
>>
>>>> So you could have:
>>>>
>>>> can_network(apache_t)
>>>>
>>>> and then to change it to only use eth0,
>>>>
>>>> can_network(apache_t,eth0_netif_t)
>>>>     
>>>
>>> I think automatic policy editing has to occur post-m4 - it doesn't
>>> make sense to me to be generating pre-m4 macros - this is going
>>> to be very hard to validate, and require a long time to compile and
>>> process.
>>>
>>> Your 1-line change expands to several hundred rules in policy.
>>>   
>>
>>
>> Perhaps I misunderstood what you were saying.
>> Dan's saying you want the netif argument to be optional,
>> and we fallback to a default label where everything's allowed if the 
>> argument is missing - so you'd only add a specific label for things 
>> you want managed by iptables.
>> That would make sense, and might be a good idea.
>>
>>
>>  
>>
> Ok so then a tool could add the following rules to only allow apache 
> and named to run on 0.
>
> type netif_eth0_t, netif_type;
> netifcon eth0 system_u:object_r:netif_eth0_t 
> system_u:object_r:unlabeled_t
> allow httpd_t netif_eth0_t:netif { tcp_recv tcp_send rawip_send 
> rawip_recv };
> allow named_t netif_eth0_t:netif { udp_recv udp_send tcp_recv tcp_send 
> rawip_send rawip_recv };
>
IMHO, I think that we _cannot_ add code to iptables to manage policy. 
This is a bad idea for a number of reasons that I've talked about in 
other emails.

This functionality should be put in system-config-security to set up the 
firewall iptables rules and manage a subset of the network related 
policy rules. This should leverage the module system so that 
system-config-security essentially owns a module that it can put it's 
rules in, remove them, etc. We can later use the policy server to limit 
this applications policy actions to just those under the primary network 
type.

I still think there are consistency issues with this, the software will 
have to be careful. All of the network rules will have to be moved to a 
single module (this is odd since apache has it's own rules, etc.. maybe 
those will be removed and all network access is defined centrally). I 
really don't like this but if you want configurable network rules there 
really isn't much choice.

The interfaces to do this work should be exported through libsemanage to 
do it seamlessly regardless of policy backend. The labels will have to 
(unfortunatly) be part of some configutation file, which is policy 
specific. This means that there needs to be some config files that are 
tightly coupled with the policy to tell these management applications 
what types they want to refer to.

Also the other issue with allow-by-default firewalls and deny rules, 
which can't be addresssed in policy at all (and I think it's a very bad 
idea for some network config app to recurse the entire policy looking 
for rules that might violate it's internal settings).



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.