Description of problem: In refpolicy the interface kernel_sendrecv_unlabeled_association contains a rule which allows sending/receiving of unlabeled packages: # temporary hack until labeling on packets is supported allow $1 unlabeled_t:packet { send recv }; This is removed in selinux-policy. Can we enable this again? Because some of my apps need this rule. I already asked on mailinglist but didn't get a response http://article.gmane.org/gmane.linux.redhat.fedora.selinux/11120 Is there any reason why the temporary hack is not acceptable? Version-Release number of selected component (if applicable): Tested with selinux-policy-2.4.6-203.el5 and selinux-policy-2.4.6-255.el5
The kernel_sendrecv_unlabeled_packets interface still exists. The corenet_non_ipsec_sendrecv interface calls it. 249 interfaces in RHEL5.4 policy call this. So I do not know what problem you are seeing.
Yes, the interface is still available but patch file "policy-20061106.patch" of selinux-policy-2.4.6-255.el5.src.rpm on line 8832 remove the following rule: allow $1 unlabeled_t:packet { send recv }; If we do not have a fix for the temporary problem, then I guess we should include the allow rule. Unless it has some security concerns. refpolicy e.g. ships the rule which makes it hard to create policy files which work for both rhel/fedora and refpolicy. policy-20061106.patch: @@ -2165,9 +2208,6 @@ ') allow $1 unlabeled_t:association { sendto recvfrom }; - - # temporary hack until labeling on packets is supported - allow $1 unlabeled_t:packet { send recv }; ')
I don't remember a reason for removing it, and since it is in upstream I guess we should add it back. Miroslav can you add it.
Fixed in selinux-policy-2.4.6-264.el5
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2010-0182.html