netdev - [RFC][PATCH 0/2] TCP connection repair

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <4F4E4084.9080804@parallels.com>
Date:	Wed, 29 Feb 2012 19:13:08 +0400
From:	Pavel Emelyanov <xemul@...allels.com>
To:	Linux Netdev List <netdev@...r.kernel.org>,
	Tejun Heo <tj@...nel.org>,
	Eric Dumazet <eric.dumazet@...il.com>
CC:	David Miller <davem@...emloft.net>
Subject: [RFC][PATCH 0/2] TCP connection repair

Hi.

Here's another approach to transparent TCP connection hijacking (previous one
was here [1]). This one is _much_ more straightforward and patches TCP code a
little bit more. I'd like to have comments on the idea itself early, so here is
the very-very basic functionality, just to demonstrate the concept.

The idea briefly is -- introduce the "repair" mode of a TCP socket. In this mode
any API call to the socket (bind/connect/sendmsg/etc.) does not result in packets
sent over the network, but instead modifies the socket locally in an expected way.

I.e., the connect() in the repair mode assigns peer's credentials to the sock and 
just turns one into the connected state without issuing SYN-s or whatever. The
bind() call on the socket under repair forcibly binds one to the desired IP and 
port ignoring any (potential) local conflicts (just like if everybody else has the
SO_REUSEADDR set). The sendmsg() just queues data for transmission (however, this
is not implemented in this set, need more thinking on how to make it symmetrical
to the receive queue), etc.

The protocol sequences are also to be get/set, so a couple of another sockopts
are introduced for this.

I think, that it makes sense to have this ability in a form of non-obscure API,
since the connection migration can be used not only by checkpoint/restore project,
but also by various load balancing solutions. E.g., a server can accept the 
connection, read the app-level header out of the stream, take the balancing 
decision based on _it_ (rather than just TCP and/or IP header) and then pass 
the existing connection to another host.

Of course, switching socket to the repair mode is only allowed for CAP_SYS_ADMIN.

What do you think?

With the set provided you can do only simple tricks, e.g. transparently passing a
connection between echo server and telnet to another echo server task and proceed 
with echoing messages.

Thanks,
Pavel

[1] http://lwn.net/Articles/454304/
--
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