netdev - Re: [PATCH net-next] tcp: provide SYN headers for passive connections

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-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 4 May 2015 10:58:05 -0400
From:	Eric B Munson <emunson@...mai.com>
To:	John Heffner <johnwheffner@...il.com>
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	Tom Herbert <tom@...bertland.com>,
	"David S. Miller" <davem@...emloft.net>, linux-api@...r.kernel.org,
	netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH net-next] tcp: provide SYN headers for passive connections

On Mon, 04 May 2015, John Heffner wrote:

> On Mon, May 4, 2015 at 12:34 AM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> >
> > From: Eric Dumazet <edumazet@...gle.com>
> >
> > This patch allows a server application to get the TCP SYN headers for
> > its passive connections.  This is useful if the server is doing
> > fingerprinting of clients based on SYN packet contents.
> >
> > Two socket options are added: TCP_SAVE_SYN and TCP_SAVED_SYN.
> >
> > The first is used on a socket to enable saving the SYN headers
> > for child connections. This can be set before or after the listen()
> > call.
> >
> > The latter is used to retrieve the SYN headers for passive connections,
> > if the parent listener has enabled TCP_SAVE_SYN.
> >
> > TCP_SAVED_SYN is read once, it frees the saved SYN headers.
> >
> > The data returned in TCP_SAVED_SYN are network (IPv4/IPv6) and TCP
> > headers.
> >
> > Original patch was written by Tom Herbert, I changed it to not hold
> > a full skb (and associated dst and conntracking reference).
> >
> > We have used such patch for about 3 years at Google.
> 
> 
> Nice idea, seems handy.  But a couple (somewhat related) questions:
> 
> * Other than convenience, are there reasons not use an existing, more
> general-purpose and portable mechanism like pcap?  (Permissions, I
> guess?)

Eric Dumazet can speak for their reasons, but we had a difficult time
guaranteeing that the data collected by libpcap was avaialble to the
accepting thread when accept() returned without making the accepting
thread wait on that data.  With this implementation, we guarantee that
userspace has access to this data when accept() returns.

> * Are there conditions where, for security purposes, you don't want an
> application to have access to the raw SYNs?

In this implementation, userspace does not have access to the raw SYN,
rather it can request a copy of the TCP and IP headers.

Eric

> 
> Thanks,
>   -John

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)