netdev - Re: Add a SOCK_DESTROY operation to close sockets from userspace

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: <CAKD1Yr1ji7AP-YKJ5kG8xYhgksNbXKKKcLoQPRsEtN020Gb_0g@mail.gmail.com>
Date:	Fri, 20 Nov 2015 07:33:53 +0900
From:	Lorenzo Colitti <lorenzo@...gle.com>
To:	Tom Herbert <tom@...bertland.com>
Cc:	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	Eric Dumazet <eric.dumazet@...il.com>,
	David Miller <davem@...emloft.net>,
	Maciej Żenczykowski <zenczykowski@...il.com>,
	Stephen Hemminger <stephen@...workplumber.org>,
	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Eric Dumazet <edumazet@...gle.com>, Erik Kline <ek@...gle.com>,
	Dmitry Torokhov <dtor@...gle.com>
Subject: Re: Add a SOCK_DESTROY operation to close sockets from userspace

On Fri, Nov 20, 2015 at 2:38 AM, Tom Herbert <tom@...bertland.com> wrote:
>> I actually don't have an issue with killing from user space that much. I
>> still recommend (and actually have started to look at it today) to add a
>> new substate for TCP TIMEWAIT and don't have any issue if we block the
>> socket for 60 seconds and send RSTs to all incoming data. This way we
>> can solve the problem Florian indicated as well as this problem. Users
>> can happily kill TCP connections then.
>>
> Neither do I have a problem with killing connections from userspace,
> but we do have to acknowledge that this is a powerful and invasive
> mechanism. I suggest:
>
> 1) We need transparency. If a third party kills a TCP connection then
> the application should be informed of specifically that. This seems
> easy enough to just pick an appropriate error number as I suggested.

I'm not wedded to ETIMEDOUT. If it means we can get this code
upstream, then we can likely do the userspace work that is needed to
ensure that applications respond correctly. Mot

> 2) We need constraints. This feature seems to be specific to a very
> narrow use case. It is not at all clear to me if there are any
> legitimate uses cases beyond Android, enabling this by default in the
> stack creates a non-zero amount of risk and liability for abuse. It
> seems like this should be an opt-in sort of feature, with a kernel
> CONFIG or maybe opt-in per socket.

I am perfectly happy for this to be behind a config option.

I do think this kernel functionality is useful in general, and as a
linux-on-laptop user I wish it was available to NetworkManager as
well, because I use Linux as well, but I think it will work for
Android if this requires a per-socket opt in setsockopt. For other
reasons we pipe all connected sockets through a userspace daemon
anyway. (But please don't tell me that that daemon should keep state
on *all* connected sockets it ever sees :-))
--
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