[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Custom labeling network interfaces



On Sat, Sep 26, 2009 at 05:15:36PM +0200, Roberto Sassu wrote:
> Hi all
> 
> i want to create a set of rules that allow the administrator to decide the 
> network interfaces on which daemons can listen to. 
> 
> To do this i created a custom policy module to define the type eth0_netif_t 
> which is bound to the eth0 interface.
> 
> type eth0_netif_t, netif_type;
> typeattribute eth0_netif_t netif_type; 
> 
> 
> ifdef(`enable_mls',`
> 
> gen_require(`type unlabeled_t;')
> netifcon eth0 gen_context(system_u:object_r:eth0_netif_t,s0 - mls_systemhigh) 
> gen_context(system_u:object_r:unlabeled_t,s0 - mls_systemhigh)
> 
> ')
> 
> Next, i executed the following command:
> 
> semanage interface -a -t eth0_netif_t eth0
> 
> Then, without adding extra rules i tried to start the sshd daemon on this 
> interface and the operation was successful. I see with the apol utility that 
> sshd is allowed to bind on the generic interface netif_t but not on 
> eth0_netif_t.
> 
> How it's possible to explicitly grant the permission to listen on eth0 for 
> each daemon which needs it?

These types are declared in the corenetwork source policy, which is compiled into the base module. For you to be able to implement policy with regard to how domains can interact with network interface object type you would have to edit the policy. For example:

This is from apache.te:

corenet_tcp_sendrecv_all_if(httpd_t)
corenet_udp_sendrecv_all_if(httpd_t)

Which means that httpd_t can send and receive tcp and udp packets using all network interfaces.
So these rule would have to be removed/replaced by rules that explicitly define how and which network interfaces httpd_t can access.

This would have to be done for each domain that has access to network interfaces via the "all_if" interfaces.

So if you really want to make this work, you should download the selinux-policy.src.rpm corresponding to the selinux-policy version that you currently have installed. Then extract the source rpm and prep the source ( apply the included patch(es) to the extracted included serefpolicy.tgz.

Then you would have to declare your custom interface object type in corenetwork.te.in and remove the "all_if" interface calls from each module that calls it. Replace it with rules the you want to enforce. When you build the policy interfaces will be automatically created by the corenetwork module. You can call these interfaces instead of using "local policy"

After you have modified the policy you would "clean the source" and repackage it (serefpolicy.tgz). Since you have already applies any included patches by redhat when you have "preparated the source" you no longer have to patch the source, thus you can remove any lines where it refers to 'patch' from the selinux-policy.spec that is included with the source rpm.

Also "bump" the version in the spec file so that it can be installed without forcing installation.

Then you would simply rebuild the selinux-policy.src.rpm using rpm-devtools (rpmbuild -ba selinux-policy.spec), and update your policy with rpm -Uvh selinux-policy*.rpm

The problem with this method though is that from that point you are the maintainer of your implemented policy, meaning you can no longer blindly update from the redhat packages if you do not want your modification to be resetted.

With EL5 this is not such a big problem since EL5 selinux-policy does not get updated very often.

hth
  
> 
> Thanks in advance for replies.
> 
> --
> fedora-selinux-list mailing list
> fedora-selinux-list redhat com
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list

Attachment: pgpuaMxPtuuYb.pgp
Description: PGP signature


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]