From: KOVACS Krisztian <hidden@balabit.hu>
To: Patrick McHardy <kaber@trash.net>
Cc: netfilter-devel@lists.netfilter.org, netdev@vger.kernel.org,
Balazs Scheidler <bazsi@balabit.hu>
Subject: Re: [PATCH/RFC 01/10] Implement local diversion of IPv4 skbs
Date: Tue, 16 Jan 2007 13:49:20 +0100 [thread overview]
Message-ID: <200701161349.21381@nienna> (raw)
In-Reply-To: <45A4D9DB.4000809@trash.net>
Hi,
On Wednesday 10 January 2007 13:19, Patrick McHardy wrote:
> > Of course it's true that doing early lookups and storing that
> > reference in the skb widens the window considerably, but I think this
> > race is already handled. Or is there anything I don't see?
>
> You're right, it seems to be handled properly (except I think there is
> a race between sk_common_release calling xfrm_sk_free_policy and f.e.
> udp calling __xfrm_policy_check, will look into that).
>
> It probably shouldn't be cached anyway, with nf_queue for example
> the window could be _really_ large.
Patrick, I seem to be out of ideas how this could be done
without "caching" the socket lookup. The problem is that it's not only
caching in some cases. For example we can do something like this:
iptables -t tproxy -A PREROUTING -s X -d Y -p tcp --dport 80 \
-j TPROXY --to proxy_ip:proxy_port
In this case the TPROXY target does a socket lookup for
proxy_ip:proxy_port and stores that socket reference in skb->sk.
Obviously if you don't do this then TCP will do a lookup on the packet's
original destination address/port and it won't work.
Unfortunately I don't see any way how this could be solved without
storing the result of the lookup... So while I agree that having that
socket reference in the skb is risky, as previously skb->sk was unused on
the input path, I simply don't have any other idea. (Unless your load
iptable_tproxy skb->sk==NULL on input is still true with these patches,
so I think there should be absolutely no problems with tproxy unused.)
Other possible problems which came to my mind:
- The previous version was missing IPv4 fragment reassembly: we obviously
need this to be able to do socket lookups, so now I've added this to
iptable_tproxy.
- IP_FREEBIND does not require NET_ADMIN capability, combined with the
relaxed source address on ip_output() this means that we provide a way to
do IPv4 address forging for unprivileged users. As we must not break
anything it looks like we need a separate socket option for disabling
output source address checks (this would obviously require NET_ADMIN).
Thoughts? I'd be especially interested in any ideas wrt. the socket
reference problems, as the other two seems to be easier to solve.
--
Regards,
Krisztian Kovacs
next prev parent reply other threads:[~2007-01-16 12:49 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-03 16:33 [PATCH/RFC 00/10] Transparent proxying patches version 4 KOVACS Krisztian
2007-01-03 16:34 ` [PATCH/RFC 01/10] Implement local diversion of IPv4 skbs KOVACS Krisztian
2007-01-10 6:46 ` Patrick McHardy
2007-01-10 9:31 ` Balazs Scheidler
2007-01-10 12:32 ` Patrick McHardy
2007-01-10 13:27 ` Ingo Oeser
2007-01-10 13:42 ` Patrick McHardy
2007-01-11 14:05 ` KOVACS Krisztian
2007-01-10 10:17 ` KOVACS Krisztian
2007-01-10 12:19 ` Patrick McHardy
2007-01-16 12:49 ` KOVACS Krisztian [this message]
2007-01-16 13:19 ` Patrick McHardy
2007-01-03 16:34 ` [PATCH/RFC 02/10] Port redirection support for TCP KOVACS Krisztian
2007-01-03 16:35 ` [PATCH/RFC 03/10] Don't do the TCP socket lookup if we already have one attached KOVACS Krisztian
2007-01-03 16:35 ` [PATCH/RFC 04/10] Don't do the UDP " KOVACS Krisztian
2007-01-03 16:36 ` [PATCH/RFC 05/10] Remove local address check on IP output KOVACS Krisztian
2007-01-10 6:47 ` Patrick McHardy
2007-01-10 10:01 ` KOVACS Krisztian
2007-02-06 14:36 ` IP_FREEBIND and CAP_NET_ADMIN (was: Re: [PATCH/RFC 05/10] Remove local address check on IP output) KOVACS Krisztian
2007-02-06 19:46 ` IP_FREEBIND and CAP_NET_ADMIN David Miller
2007-01-03 16:36 ` [PATCH/RFC 06/10] Create a tproxy flag in struct sk_buff KOVACS Krisztian
2007-01-03 16:37 ` [PATCH/RFC 07/10] Export UDP socket lookup function KOVACS Krisztian
2007-01-03 16:37 ` [PATCH/RFC 08/10] iptables tproxy table KOVACS Krisztian
2007-01-10 12:40 ` Patrick McHardy
2007-01-03 16:38 ` [PATCH/RFC 09/10] iptables TPROXY target KOVACS Krisztian
2007-01-10 12:45 ` Patrick McHardy
2007-01-03 16:38 ` [PATCH/RFC 10/10] iptables tproxy match KOVACS Krisztian
2007-01-03 17:23 ` [PATCH/RFC 00/10] Transparent proxying patches version 4 Evgeniy Polyakov
2007-01-08 20:30 ` KOVACS Krisztian
2007-01-03 19:33 ` Lennert Buytenhek
2007-01-04 12:13 ` KOVACS Krisztian
2007-01-04 12:16 ` Lennert Buytenhek
2007-01-07 14:11 ` Harald Welte
2007-01-07 16:11 ` Lennert Buytenhek
2007-01-07 23:58 ` Harald Welte
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=200701161349.21381@nienna \
--to=hidden@balabit.hu \
--cc=bazsi@balabit.hu \
--cc=kaber@trash.net \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@lists.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).