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:	Thu, 19 Nov 2015 18:25:33 -0800
From:	Maciej Żenczykowski <zenczykowski@...il.com>
To:	Tom Herbert <tom@...bertland.com>
Cc:	Lorenzo Colitti <lorenzo@...gle.com>,
	Eric Dumazet <eric.dumazet@...il.com>,
	David Miller <davem@...emloft.net>,
	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	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

> No, I mean something that kills connections where previously this did
> not happen. The fact that this is done at the process level does not
> justify that it is a right to at do connections. Besides, if you
> really intend to do this then provide a privileged process a means to
> close *any* open file descriptor in the system (why stop at TCP
> sockets)!

There is little reason to be able to kill random processes arbitrary
file descriptors,
while there is ample reason to be able to kill network connections.

Network connections can already (and often are) be killed by the network, but
that's far less true for files (although IO errors and emergency fs remount r/o
can cause similar behaviour).

Userspace doesn't expect file descriptors to local files to suddenly break,
while it already has to handle network connections timing out and the like.

Perhaps we shouldn't be using the word 'kill'.  We're not really killing
these sockets, nor closing them, we just need an out-of-band mechanism
for flagging them with some sort of error (ie. force timing them out, or force
resetting them).

That said, one can certainly come up with cases where killing arbitrary file
descriptors would make sense (or more likely switching them from r/w to r/o
mode or replacing them with some sort of /dev/null like file
descriptor instead).
Example use cases would be umounting a removable usb key which is in the
process of being pulled out of the machine (or was already pulled
out), or remounting
a file system readonly (which still has r/w open files).
--
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