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/7] netfilter: introduce new chain type for local socket input
Date: Tue, 29 Sep 2015 13:12:13 +0200 [thread overview]
Message-ID: <1443525140-13493-1-git-send-email-daniel@zonque.org> (raw)
Here is a patch set that enables for full support for match rules
that take into account information about the local receiver socket.
Such rules allow administrators to implement per-application or
per-container firewalls which filter any type of network traffic
directed to or originated from a set of processes on a system,
independent of, for instance, local or remote port numbers.
In theory, such rules are already supported through the 'meta' and
'socket' rule types, but they currently do not work for ingress packets
delivered to unestablished listener sockets. NF_INET_LOCAL_IN chains
are iterated once the IP stack decides a packet is directed to the
local system, but before the local listener socket is determined.
Consequently, filter rules that are based on information derived from
the listener socket cannot be used reliably.
This patch set introduces a new chain type (NF_INET_LOCAL_SOCKET_IN)
that is iterated at a later point in time than NF_INET_LOCAL_IN, after
the listener socket demux has succeeded. Chains of this type are hence
only looked at _if_ there is a local listener.
The input paths for TCP and UDP for IPv4 and IPv6 are patched for
the new hook-up, as well as SCTP and DCCP.
Possible performance penalties for setups in which this new type is
not used need to be considered, but I lack a good test case for that.
I'm sure some people reading this do have proper test scenarios they
can run with these patches applied. I'd be very interested in these
numbers.
For SCTP and DCCP, I admittedly lack a proper test case as well, and
for UDP, I'm aware of a possible deadlock due to nf_hook() being called
under hslot->lock when the stack is flushed preliminarily from
__udp[46]_lib_mcast_deliver(). That's fixable, but I've kept it simple
for this RFC.
Only nftables is supported so far, but enabling iptables as well would
be straight forward.
I also have trivial patches for libnftnl and nftables to enable
the userspace part.
I'd appreciate some feedback about this approach.
Thanks,
Daniel
Daniel Mack (7):
netfilter: add socket to struct nft_pktinfo
netfilter: nft_meta: look at pkt->sk rather than skb->sk
netfilter: add NF_INET_LOCAL_SOCKET_IN chain type
net: tcp_ipv4, udp_ipv4: hook up LOCAL_SOCKET_IN netfilter chains
net: tcp_ipv6, udp_ipv6: hook up LOCAL_SOCKET_IN netfilter chains
net: sctp: hook up LOCAL_SOCKET_IN netfilter chains
net: dccp: hook up LOCAL_SOCKET_IN netfilter chains
include/net/netfilter/nf_tables.h | 2 ++
include/uapi/linux/netfilter.h | 1 +
net/dccp/ipv4.c | 14 +++++++++++++-
net/dccp/ipv6.c | 14 +++++++++++++-
net/ipv4/netfilter/iptable_filter.c | 1 +
net/ipv4/netfilter/nf_tables_ipv4.c | 14 ++++++++------
net/ipv4/tcp_ipv4.c | 8 ++++++++
net/ipv4/udp.c | 15 +++++++++++++++
net/ipv6/netfilter/nf_tables_ipv6.c | 14 ++++++++------
net/ipv6/tcp_ipv6.c | 8 ++++++++
net/ipv6/udp.c | 9 +++++++++
net/netfilter/nf_tables_inet.c | 3 ++-
net/netfilter/nft_meta.c | 7 ++++---
net/sctp/input.c | 11 ++++++++++-
14 files changed, 102 insertions(+), 19 deletions(-)
--
2.5.0
next reply other threads:[~2015-09-29 11:12 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-29 11:12 Daniel Mack [this message]
2015-09-29 11:12 ` [PATCH RFC 1/7] netfilter: add socket to struct nft_pktinfo Daniel Mack
2015-09-29 18:25 ` Eric W. Biederman
2015-09-29 11:12 ` [PATCH RFC 2/7] netfilter: nft_meta: look at pkt->sk rather than skb->sk Daniel Mack
2015-09-29 13:37 ` kbuild test robot
2015-09-29 11:12 ` [PATCH RFC 3/7] netfilter: add NF_INET_LOCAL_SOCKET_IN chain type Daniel Mack
2015-09-29 21:19 ` Florian Westphal
2015-09-30 7:24 ` Daniel Mack
2015-09-30 7:40 ` Jan Engelhardt
2015-09-30 8:54 ` Daniel Mack
2015-09-30 21:48 ` Florian Westphal
2015-10-01 9:04 ` Daniel Mack
2015-10-01 17:13 ` Marcelo Ricardo Leitner
2015-10-01 21:07 ` Daniel Mack
2015-10-01 21:34 ` Marcelo Ricardo Leitner
2015-10-02 11:07 ` Pablo Neira Ayuso
2015-10-02 13:52 ` Daniel Mack
2015-09-29 11:12 ` [PATCH RFC 4/7] net: tcp_ipv4, udp_ipv4: hook up LOCAL_SOCKET_IN netfilter chains Daniel Mack
2015-09-29 11:12 ` [PATCH RFC 5/7] net: tcp_ipv6, udp_ipv6: " Daniel Mack
2015-09-29 11:12 ` [PATCH RFC 6/7] net: sctp: " Daniel Mack
2015-09-29 11:12 ` [PATCH RFC 7/7] net: dccp: " Daniel Mack
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=1443525140-13493-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).