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]
Message-ID: <CALCETrXHdSVC-YLsdjHxAp3rU2gGFZaz8NNgaTKYgjM-ah3z+A@mail.gmail.com>
Date:	Tue, 25 Nov 2014 13:39:39 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	David Miller <davem@...emloft.net>
Cc:	Willem de Bruijn <willemb@...gle.com>,
	Network Development <netdev@...r.kernel.org>,
	Richard Cochran <richardcochran@...il.com>
Subject: Re: [PATCH rfc 1/4] net-timestamp: pull headers for SOCK_STREAM

On Tue, Nov 25, 2014 at 11:54 AM, David Miller <davem@...emloft.net> wrote:
> From: Willem de Bruijn <willemb@...gle.com>
> Date: Tue, 25 Nov 2014 14:52:00 -0500
>
>> On Tue, Nov 25, 2014 at 1:42 PM, David Miller <davem@...emloft.net> wrote:
>>> From: Willem de Bruijn <willemb@...gle.com>
>>> Date: Tue, 25 Nov 2014 12:58:03 -0500
>>>
>>> What's the harm in exposing the headers?  Either it's harmful, and
>>> therefore doing so for UDP is bad too, or it's harmless and
>>
>> Headers may expose information not available otherwise. I don't
>> immediately see critical problems, but that does not mean that they
>> might not lurk there.
>>
>> We so far avoid exposing the sequence number, though keeping it hidden
>> is more about third parties. More in general, unprivileged processes
>> may start requesting timestamps only to learn tcp state that they
>> should either get from tcpinfo or cannot currently get at all, likely
>> for good reason. A far-fetched example is identifying admin iptables
>> tos mangling rules by reading the tos bits at the driver layer. At least
>> on my machine, iptables -L is privileged.
>>
>>> we should probably leave it alone to not risk breaking anyone.
>>
>> That's fair. I sent it for rfc first for that reason. I won't resubmit
>> unless more serious concerns are raised.
>
> I just worry about the potential breakage.
>
> Your concerns are valid... I honestly don't know what we should do here.
> Both choices have merit.

Here's a scenario in which giving the headers might be dangerous:

Suppose I create a network namespace that's designed to contain
something, e.g. a Tor or Tor-like client, that shouldn't know any of
its public addressing information.  I might assign something like a
tunnel interface to the namespace, but, if the contained code can get
lower-level headers, it might learn something that would identify the
*other* end of the tunnel, which wouldn't be so good.  Admittedly,
this would be just one of several things that would require care to
get this right.

Also, what happens if the output is transformed by ipsec?  Does the
timestamp message show the ciphertext?

TBH, I'd rather send no payload at all and have an scm message that
the sender provides that specifies a cookie identifying the particular
sent data.  But that ship mostly sailed awhile ago.

For bytestreams, though, isn't this all new in 3.18?  Or am I off by a release.

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ