On 03/27/2015 11:47 AM, Pablo Neira Ayuso wrote:
On Fri, Mar 27, 2015 at 10:48:51AM +0100, Daniel Borkmann wrote:
On 03/27/2015 03:10 AM, Pablo Neira Ayuso wrote:
What started a simple cgroup match extension is turning into a more
complicated thing. And you want to do firewalling with this, which
doesn't work for other socket families than TCP and UDP.
Right, so for me it started out as a simple outgoing match extension
for skb->sk and this should be protocol agnostic, for example, SCTP
sets the skb owner in its output path, so the cgroup id would work
there, too. (That should be the case for every protocol that's doing
proper socket accounting.)
People have since then seen a use case for accounting, so support
was added for local-in (which we try to fix), where it's being used
in Tizen OS apparently, but the idea for realizing a per-application,
per-container, ... firewall for both filtering and accounting sounds
appealing to me.
Yes, but the more I look into this the more I'm convinced that the nf
socket infrastructure was not designed for generic socket-based
firewalling.
This is basically there for TPROXY and very simple socket filtering
scenarios. This really needs more thinking.
Okay, I understand, if we can come up with a better, more generic solution
to this use-case, I'm all for it.
So, I'd like to get this right for iptables and am also eager to help
out fixing this in nft.
I'm just going to send two-liner patch for nft to get this working at
least in the limited supported scenarios that we already have.
Okay.
Thanks again,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
