James Morris wrote: > Last year, I posted a set of patches to allow iptables matching against > associated processes for incoming packets. With this patch, I'm proposing > a much simpler alternative and solictiting feedback on the idea from other > networking developers. > > For the original patches and discussion, see: > http://marc.theaimsgroup.com/?l=linux-netdev&m=113027175208707&w=2 > and > http://people.redhat.com/jmorris/selinux/skfilter/ > > The purpose of the patches was to allow incoming owner matching to work > cleanly, as well as allow integration of SELinux and Netfilter apps > (iptables, conntrack etc). This would also allow the existing SELinux > networking hooks to be replaced in a more powerful and expressive way. > > The skfilter patches posted are quite invasive, and probably require > moving all Netfilter 'input' processing to the socket layer, with several > unresolved issues.
Moving the netfilter input processing to the socket layer would actually be a nice solution in my opinion, but its unfortunately not possible without changing user-visible behaviour. SNAT is performed in LOCAL_IN before filtering, but we need the already SNATed packet for the socket lookup. So I concluded that the only possibility is to keep the existing hooks and have a seperate skfilter INPUT chain. The conntrack confirmation problem can be solved by registering the ip_confirm hook with the socket hooks when they are compiled in. >From a pure netfilter POV it would still be nice to have the socket hooks for userspace queueing in socket context and filtering hard to track protocols. My only question is: if I would port the skfilter patches to the current kernel today and fix the unresolved issues, would you still prefer this approach? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
