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 17:00:39 -0800
From:	Maciej Żenczykowski <maze@...gle.com>
To:	David Miller <davem@...emloft.net>
Cc:	Lorenzo Colitti <lorenzo@...gle.com>,
	Hannes Frederic Sowa <hannes@...essinduktion.org>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Stephen Hemminger <stephen@...workplumber.org>,
	Linux NetDev <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

>> 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.
>
> Netfilter could perform signalling on skb->sk when it drops packets.
>
> Your example is actually a argument _for_ doing this in the kernel.

That only (currently) works if a socket actually tries to send something.

Idle sockets (for example a socket used for push notification from the
remote server) still end up blocking forever.

If you were to, whenever the firewall configuration is changed,
iterate through all sockets in the system and generate a pair of fake
0-data packets (for both directions) for every socket to see if it
would get blocked by the firewall... but that seems quite insane.
--
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