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. > 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. > I was thinking that if we add --lookup-sock in a second revision, > the man-page would _clearly_ need to describe that when being used > w/o the lookup option, it only works for protocols making use of > early demuxes on ingress, and when being being used with the lookup > option, we would have TCP/UDP covered on ingress. Not even that, it seems to me this will not work for UDP multicast either. > Would that be fine as a start to have this documented? I think this is not going to work the way users expect, so I would either schedule INPUT cgroup filtering for removal (to get this aligned with the owner match) or document how limited this is. > Or, would nft also require niche protocols like SCTP/DCCP to be > supported for the lookup up-front? > > What I've seen so far is, that besides the basic xt_sctp matching, > the perhaps biggest request SCTP users might have, is that association > tracking currently is missing for the conntracker and ipvs to make > their multi-homed use-cases work, but I guess I'm starting to get > off-topic. :) Yes, that's a different front ;-). -- 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
