Re: Iptables discussion

[Joshua Brindle <jbrindle@tresys.com>]

Ivan Gyurdiev wrote:

>>>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 };
>>>      
>>>
>
>Those seem reasonable.
>
>  
>
rawip_* isn't necessary and should not be added

>>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.
>>    
>>
>
>I haven't seen any of those, can you point me somewhere?
>
>  
>
earlier in this thread, the consistency arguments (iptables having a 
run-time state vs. a persistant state, contrary to the persistant state 
of the selinux policy)

>>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. 
>>    
>>
>
>I don't understand why we have two sets of rules to manage the same
>thing.
>
>  
>
there will always be 2 sets, we are trying to keep them consistent. 
Also, iptables can state alot more than the policy currently supports. 
Adding this to iptables means defining certain types of 'supported' 
rules to add to the policy. Rather than do that this should be done from 
the interface that already limits what kind of rules you can do and 
simplifies them for the user (system-config-network{,-tui}

>>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.
>>    
>>
>
>Good idea...
>
>  
>
>>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. 
>>    
>>
>
>The labels can be inferred from the card name, if necessary.
>
>  
>
no, implicit labeling considered harmful. This destroys the concept of 
equivalence classes (which is what types are). You should be able to 
make 2 interfaces equivalent without having a set of rules for each of them.

>>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).
>>    
>>
>
>Deny rules could possibly be ... denied :) on an selinux-enabled system.
>
>  
>
that means the app needs to get a full copy of the policy and try to 
find allow rules that could violate the deny state of the iptables rule, 
this is bad

--
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.