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]

Date:	Tue, 17 Nov 2015 20:31:10 -0800
From:	Tom Herbert <tom@...bertland.com>
To:	Lorenzo Colitti <lorenzo@...gle.com>
Cc:	Linux Kernel Network Developers <netdev@...r.kernel.org>,
	Eric Dumazet <edumazet@...gle.com>, Erik Kline <ek@...gle.com>,
	Maciej Żenczykowski <maze@...gle.com>,
	Dmitry Torokhov <dtor@...gle.com>
Subject: Re: Add a SOCK_DESTROY operation to close sockets from userspace

On Tue, Nov 17, 2015 at 8:23 PM, Lorenzo Colitti <lorenzo@...gle.com> wrote:
> On Wed, Nov 18, 2015 at 12:56 PM, Tom Herbert <tom@...bertland.com> wrote:
>>> The patch series only implements SOCK_DESTROY for TCP sockets,
>>> but the mechanism can be extended to any protocol family that
>>> supports the sock_diag interface.
>>>
>> I assume that SIOCKILLADDR was restricted to only closing connections
>> related to add addresses going away, but SOCK_DESTROY seems to allow
>> arbitrarily killing connections without publicized cause.
>
> Closing connections on deleted IP addresses is the main use of
> SIOCKILLADDR, but the ioctl also supports closing all connections on a
> userspace-provided IP address.
>
> However, those semantics are not enough in some cases. For example:
> when a VPN client connects, for security reasons (e.g., to make it
> harder for on-link attackers to attack cleartext apps), traffic from
> unprivileged applications is no longer permitted on non-VPN
> interfaces. All unprivileged traffic is routed over the VPN.
> Currently, existing TCP connections just hang, which typically annoys
> the user. It would be better if we had the ability to close those
> connections with SOCK_DESTROY.
>
> SIOCKILLADDR cannot do that because it is inappropriate to
> indiscriminately kill TCP connections that are not on the VPN - if
> nothing else, one of those TCP connections could be the one that is
> providing the VPN itself.
>
>> Minimally, the application should get at
>> least get a clear error that the local host administratively killed
>> the connection, ETIMEDOUT does not provide that.
>
> I don't know why ETIMEDOUT was chosen (we've been running this since
> 2008), but I think it's because:
>
> 1. All Internet applications have to be prepared to receive ETIMEDOUT
> on TCP sockets.
> 2. ETIMEDOUT is the error that those applications would have gotten
> anyway if they had waited a few minutes.
>
> It's certainly possible to use something other than ETIMEDOUT, though
> I don't know what error code would be appropriate. Perhaps we can make
> it configurable by the caller.

How about ENETRESET?

Also, it would be nice if the part about doing the close on the
protocol socket were abstracted out as protoop in itself, maybe
something like admin_close op. We'll have other use cases where the
stack wants to close a socket outside of user request or normal
protocol operations (KCM does this for instance).

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