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:	Fri, 20 Nov 2015 09:19:25 +0900
From:	Lorenzo Colitti <lorenzo@...gle.com>
To:	David Miller <davem@...emloft.net>
Cc:	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Stephen Hemminger <stephen@...workplumber.org>,
	"netdev@...r.kernel.org" <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 Thu, Nov 19, 2015 at 2:53 PM, David Miller <davem@...emloft.net> wrote:
> What I object to is userspace making reachability decisions, not
> whether SOCK_DESTROY closes the socket in one way or the other.

To be fair: userspace already makes reachability decisions. Using
iptables and ip rules, it can configure arbitrarily complex policies
such as "cause new TCP connections from port 12742 to port 443 by UID
12345 to fail with fast ECONNRESET". Userspace can change those
policies at any time.

I think what's new in this patchset is that today userspace can only
do that at connection establishment time; this patchset would allow
re-evaluating reachability for established connections as well.

But I do think this is needed. In addition to the "network
disconnected" and "VPN connected" examples, I already provided here's
another example where it's hard for the kernel to make reachability
decisions.

Android and iOS have settings that the user can use to allow or
disallow an app from using cellular data. If the user disables cell
data for app X, userspace will tell the kernel to drop all that app's
packets, but it can't prevent an app from hanging on read() or write()
on a socket that the app already had (e.g., one it had opened before
the user changed the setting and had left open for latency reasons).

In this case, userspace knows that that app's connections are now
unusable because it configured an iptables rule to block them. The
kernel doesn't really know until it the time comes to send a packet,
and maybe not even then.
--
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