Message-ID: <20150930214852.GA8443@breakpoint.cc>
Date:	Wed, 30 Sep 2015 23:48:52 +0200
From:	Florian Westphal <fw@...len.de>
To:	Daniel Mack <daniel@...que.org>
Cc:	Florian Westphal <fw@...len.de>, pablo@...filter.org,
	daniel@...earbox.net, netfilter-devel@...r.kernel.org,
	netdev@...r.kernel.org, balazs.scheidler@...abit.com
Subject: Re: [PATCH RFC 3/7] netfilter: add NF_INET_LOCAL_SOCKET_IN chain type

Daniel Mack <daniel@...que.org> wrote:
> Of course you can drop certain packets at this point, depending on other
> details. Say, for instance, you want to match all packets that are
> received by a certain task and that are originated from IP addresses of
> a specific subnet, and drop the rest. Rather than adding matches to your
> global firewall configuration for all the ports that tasks may or may
> not listen on, you can just do it on a higher level, from the
> perspective of an administrator. If you decide to let your web server
> listen on another port as well, no firewall rule configuration change is
> needed at all.

We don't have per application configurations, not even with these
patches...?
The configuration is still global/per netns?

> Another use case is accounting. If you want to know how much traffic a
> certain service or application in your system has caused, you don't want
> to match all its ports to firewall rules just in order to get that
> information. Instead, you can now derive that information on a
> per-application base. With this patch set, this even works just fine for
> multicast listeners, which is something that is currently impossible to
> achieve otherwise.

> > So the only 'benefit' is that netcls id is available; but
> > a) why is that even needed and
> 
> It's currently the only way of realizing application-level firewalls,
> and it'd be an awesome feature if it actually worked.

Application level firewall makes me think of proxies.
What exactly are we talking about?
Can you provide examples?

> > b) is such a huge sledgehammer just for net cgroup accounting
> > worth it?
> 
> I really don't know if this approach is intrusive enough to make it
> qualify as sledgehammer. I'd like to see some real-world benchmarks and
> have proof there is a performance decrease for setups that don't use
> such chains.

We have static keys for nf hooks so there is no performance decrease if
no netfilter hooks are active.

HOWEVER, this discussion seems to hint at the opposite, namely that this
will turn into a mandatory or at least auto-enabled feature.

But regardless, I called it a sledgehammer not because of performance
concerns but because just to get this proposed socket matching facility we
now have to put hooks into all protocol handlers and commit to keeping them
there forever.

Also, some time ago Eric suggested to allow binding to tcp ports
from packet sockets to implement userspace-driven TCP stacks (i.e.
kernel would just queue raw frames for the given quadruple withput
caring about ordering etc).

If we allow this proposed change, we'd also have to extend that
with these hooks.

Next time someone mentions that we don't have application matching
but only sk/cgroup tests. Are we then going to consider doing task lookups?

> > For deterministic ingress filtering you can only rely on what
> > is contained in the packet.
> 
> Why so? For deterministic ingress filtering of traffic directed to a
> local socket, you can as well rely on information associated with that
> socket. And this is what application-level firewall rule sets are all about.

Application not running -> different behaviour.  I'm sure thats obvious
to you, but I'm not sure if its obvious to users that their
'match on net clsid 42' won't work anymore when that service isn't running.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists