From: KOVACS Krisztian <hidden@balabit.hu>
To: Patrick McHardy <kaber@trash.net>
Cc: netfilter-devel@lists.netfilter.org, netdev@vger.kernel.org
Subject: IP_FREEBIND and CAP_NET_ADMIN (was: Re: [PATCH/RFC 05/10] Remove local address check on IP output)
Date: Tue, 6 Feb 2007 15:36:18 +0100 [thread overview]
Message-ID: <200702061536.18800@nienna> (raw)
In-Reply-To: <45A48BEB.2070207@trash.net>
On Wednesday 10 January 2007 07:47, Patrick McHardy wrote:
> KOVACS Krisztian wrote:
> > ip_route_output() contains a check to make sure that no flows with
> > non-local source IP addresses are routed. Unfortunately this check
> > makes it completely impossible to use non-local bound sockets as no
> > outbound packets will make through the stack.
> >
> > This patch moves the interface lookup to the multicast-specific code
> > path as that is the only real user of the interface data looked up.
> >
> > Signed-off-by: KOVACS Krisztian <hidden@balabit.hu>
> >
> > ---
> >
> > net/ipv4/route.c | 13 +++++--------
> > 1 files changed, 5 insertions(+), 8 deletions(-)
> >
> > diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> > index 537b976..bb1158a 100644
> > --- a/net/ipv4/route.c
> > +++ b/net/ipv4/route.c
> > @@ -2498,11 +2498,6 @@ #endif
> > ZERONET(oldflp->fl4_src))
> > goto out;
> >
> > - /* It is equivalent to inet_addr_type(saddr) == RTN_LOCAL */
> > - dev_out = ip_dev_find(oldflp->fl4_src);
> > - if (dev_out == NULL)
> > - goto out;
> > -
>
> I'm not sure how exactly this is used by applications, but couldn't you
> restrict this to sockets without freebind?
As it turned out since I've submitted this patch simply removing the
branch in the quoted patch above is not good, as that'd allow all local
users to generate connections from a non-local IP address. (Since setting
IP_FREEBIND does not require CAP_NET_ADMIN.)
I've attempted to restrict the removal of the check to certain sockets,
but it is more difficult than expected. It'd require touching a lot of
areas of the kernel code, as the socket is not available at times where
an output routing lookup is requested.
In fact the only thing available when making the decision in
ip_route_output_slow() is a struct flowi. I've tried to stuff a flag bit
into "struct flowi", but that solution seems to be very risky, as the
value for "struct flowi->flags" is not consulted at a lot of places. IMHO
the result would be far from pretty... (And I have to admit that I don't
really know what flowi->flags is used for. I've found no in-tree user of
that field. The only defined flag bit, FLOWI_FLAG_MULTIPATHOLDROUTE, has
no in-tree user either.)
And even if we have this flag in place, it's not enough to set it for
certain sockets in ip_route_connect(): this would not handle SYN+ACK or
ACK packets sent in response for redirected TCP connection attempts. And
who knows what else is still hiding there: ip_route_output_*() calls are
pretty much everywhere in the whole net/ipv4 directory.
So I think the cleanest solution would be to require CAP_NET_ADMIN for
IP_FREEBIND. This way, a non-root process would not be allowed to bind to
a non-local socket, thus it would not be possible to initiate connections
from a non-local IP.
As this would be a change in the kernel ABI, me and Balazs have tried to
search for applications using the IP_FREEBIND option using Google
codesearch (www.google.com/codesearch).
Outside libc and kernel, we've found only three applications that mention
this option:
* socat: which allows setting all socket options by the user (I doubt
using IP_FREEBIND with socat has any meaningful use)
* strace: to be able to dump IP_FREEBIND
* qemu: for emulating Linux system calls
Neither of these require IP_FREEBIND as core functionality, and will
probably work if IP_FREEBIND would be bound to CAP_NET_ADMIN.
So the question is: shall we take the IP_FREEBIND approach, this would
change a hardly ever used interface by requiring CAP_NET_ADMIN
capabilities, or we should try finding all the scattered places in the
Linux IP stack which does a route lookup?
--
Regards,
Krisztian Kovacs
next prev parent reply other threads:[~2007-02-06 14:36 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
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 ` KOVACS Krisztian [this message]
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=200702061536.18800@nienna \
--to=hidden@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).