From: Daniel Mack <daniel@zonque.org>
To: pablo@netfilter.org
Cc: daniel@iogearbox.net, netfilter-devel@vger.kernel.org,
netdev@vger.kernel.org, fw@strlen.de,
balazs.scheidler@balabit.com, Daniel Mack <daniel@zonque.org>
Subject: [PATCH RFC 0/3] Allow postponed netfilter handling for socket matches
Date: Wed, 16 Sep 2015 17:42:57 +0200 [thread overview]
Message-ID: <1442418180-14322-1-git-send-email-daniel@zonque.org> (raw)
I'm re-addressing the issue of matching socket meta information for
non-established sockets that has been discussed a while ago:
http://article.gmane.org/gmane.comp.security.firewalls.netfilter.devel/56877
Being able to reliably match on net_cls cgroup ids is crucial in
order to build a per-application or per-container firewall rules
which don't leak ingress packets. Such a feature would be very
useful to have.
A previous attempt to fix the currently existing issues was to call
out to the early demuxing helper functions from the meta matching
callbacks, but that doesn't suffice because it doesn't address the
case of multicast UDP and other, more complex lookup methods
implemented in various protocol handlers.
This patch set outlines a different approach by adding a flag to
'struct sk_buff' called 'nf_postponed'. This flag is set by
nft_meta_get_eval() in case a decision cannot be made due to a missing
skb->sk. skbs flagged that way will then be ran through the netfilter
chain processor again after the protocol handlers did the real socket
lookup. A small addition to 'struct nft_pktinfo' is needed so that the
matching callbacks can access the socket that was passed into
nf_hook().
Note that the new flag does not actually bloat 'struct skb_buff',
because it still fits into the 'flags1' bitfield. Also, the extra
netfilter chain iteration will not be done by any subsequent packet in
the same stream, as for those, the early demux code will set skb->sk.
The patch set is obviously not yet finished, because a lot more
protocol handlers need to be patched. Right now, I only addressed
tcp_ipv4. Before I do that, I want to get some feedback on the
approach, so please let me know what you think.
Thanks,
Daniel
Daniel Mack (3):
netfilter: add socket to struct nft_pktinfo
netfilter: nft_meta: mark skbs for postponed filter processing
net: tcp_ipv4: re-run netfilter chains for marked skbs
include/linux/skbuff.h | 3 ++-
include/net/netfilter/nf_tables.h | 2 ++
net/ipv4/tcp_ipv4.c | 10 ++++++++++
net/netfilter/nft_meta.c | 9 ++++++---
4 files changed, 20 insertions(+), 4 deletions(-)
--
2.5.0
next reply other threads:[~2015-09-16 15:42 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-16 15:42 Daniel Mack [this message]
2015-09-16 15:42 ` [PATCH RFC 1/3] netfilter: add socket to struct nft_pktinfo Daniel Mack
2015-09-16 15:42 ` [PATCH RFC 2/3] netfilter: nft_meta: mark skbs for postponed filter processing Daniel Mack
2015-09-16 15:43 ` [PATCH RFC 3/3] net: tcp_ipv4: re-run netfilter chains for marked skbs Daniel Mack
2015-09-16 21:21 ` [PATCH RFC 0/3] Allow postponed netfilter handling for socket matches Florian Westphal
2015-09-17 10:04 ` Daniel Mack
2015-09-17 16:00 ` Florian Westphal
2015-09-21 16:52 ` Daniel Mack
2015-09-21 19:05 ` Florian Westphal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1442418180-14322-1-git-send-email-daniel@zonque.org \
--to=daniel@zonque.org \
--cc=balazs.scheidler@balabit.com \
--cc=daniel@iogearbox.net \
--cc=fw@strlen.de \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=pablo@netfilter.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).