Firewall rules using SELinux context (Was Re: RFE: FireKit)

[Daniel J Walsh]

On 07/27/2009 04:23 AM, Glen Turner wrote:
> On 25/07/09 07:14, Simo Sorce wrote:
> 
>> What's the value of labeling packets based on source/destination ports ?
>> Doesn't seem to add any new information.
> 
> Indeed.
> 
> Security marking can add an additional IP header, so that a multilevel
> operating system on one machine can pass those multiple levels of data
> across an intervening network.
> 
This is all fascinating conversation.  But the question still arises, why can't anyone use SECMARK/IPTABLES rules on a Targeted policy system.  My opinion is that it is still too difficult.

The rules for name_connect, name_bind, prevent SELinux domains from connecting or listening on random ports, and that seems to work fairly well.

But if you want to configure SELinux to only allow httpd_t to listen on eth0 or only to connect to host mysql.redhat.com you had better invest in some SELinux courses.  I would have no idea how to get that right.  This is the problem.

Maybe the tools are all present but you need a masters in SELinux policy to write these rules, which most admin can state fairly easily with iptables rules, using the -Z

Currently SELinux policy has to allow all domains to listen to the unlabeled_t packets, so changing apache_t to listen to only apache_packet_t is a major change in policy.  How does an admin do this,  Not a policy writer.  If the admin needs to write a single TE rule, we fail.  And sadly usability of SECMARK/NetworkLabaling has failed Targeted policy.

I have said for two years I would like to allow apache to connect on localhost to port 80, but no other connections.  httpd also needs to be able to listen on all apache ports on all network devices and send packets back and forth.  If the iptables rules get removed the apache has to be removed to allow httpd_t has to become more permissive, it can not break because packets are no longer labeled.