netdev - Re: [PATCH rfc 1/4] net-timestamp: pull headers for SOCK

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:	Tue, 25 Nov 2014 14:52:00 -0500
From:	Willem de Bruijn <willemb@...gle.com>
To:	David Miller <davem@...emloft.net>
Cc:	Network Development <netdev@...r.kernel.org>,
	Andy Lutomirski <luto@...capital.net>,
	Richard Cochran <richardcochran@...il.com>
Subject: Re: [PATCH rfc 1/4] net-timestamp: pull headers for SOCK_STREAM

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
>
>> From: Willem de Bruijn <willemb@...gle.com>
>>
>> When returning timestamped packets on the error queue, only return
>> the data that the application initially sent: not the protocol
>> headers.
>>
>> This changes the ABI. The TCP interface is new enough that it should
>> be safe to do so. The UDP interface could be changed analogously with
>>
>> +  else if (sk->sk_protocol == IPPROTO_UDP)
>> +    skb_pull(skb, skb_transport_offset(skb) + sizeof(struct udphdr));
>>
>> Tested with Documentation/networking/timestamping/txtimestamp -l 60 -x
>>
>> Signed-off-by: Willem de Bruijn <willemb@...gle.com>
>
> 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.
--
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