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: <CALx6S34_ZHrJg5rtt-72LoHUdKNcBc=7qNNrAxnBAKVMjo7LZQ@mail.gmail.com>
Date:	Thu, 19 Nov 2015 15:24:26 -0800
From:	Tom Herbert <tom@...bertland.com>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	Lorenzo Colitti <lorenzo@...gle.com>,
	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 Thu, Nov 19, 2015 at 2:38 PM, Hannes Frederic Sowa
<hannes@...essinduktion.org> wrote:
>
>
> On Thu, Nov 19, 2015, at 23:33, Lorenzo Colitti wrote:
>> 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.
>
> Why? If it is an administrator only option it does not make sense to
> hide it behind a sysctl. Applications using this interface could also
> easily change the sysctl because they probably have the same privileges.
> A Kconfig option seems to be not useful to me either.
>

A sysctl is obviously useless, but Kconfig option is good. There is no
way I want this option enabled in my data center without any
demonstrated need for it. History has shown many times, that once we
allow options like this to be enabled in the kernel, they will
inevitably be used often without our (kernel experts') knowledge or
supervision. In too many cases this blows up in our faces (there has
been at least one outage @FB caused by someone inadvertently
exercising an otherwise obscure kernel feature).

Tom
--
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