Re: [PATCH][RFC] Security marking

[Patrick McHardy <kaber@trash.net>]

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?