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: <CANP3RGcPRzSL06qZB9oewrvN_AUUodnYzXQO=itoK40z64x8Yw@mail.gmail.com>
Date:	Wed, 18 Nov 2015 23:19:03 -0800
From:	Maciej Żenczykowski <zenczykowski@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	Lorenzo Colitti <lorenzo@...gle.com>, hannes@...essinduktion.org,
	Eric Dumazet <eric.dumazet@...il.com>,
	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

> What I object to is userspace making reachability decisions, not
> whether SOCK_DESTROY closes the socket in one way or the other.

Privileged userspace can already make these decisions today, whether
it is by killing processes with open sockets, or by turning interfaces
up and down or by reconfiguring the firewall and/or the routing
rules/tables, or by injecting spoofed TCP reset packets (via tap).
It's just *very* inconvenient to do and error prone.

Another example: privileged userspace could ptrace the userspace apps
and via code injection call close() on the app's behalf and reopen the
file descriptor to some null routed destination so it behaves like if
it was timed out / unreachable.

In general the statement that (appropriately privileged) 'userspace
should not be able to do something' is wrong - about the only
exception I can think of being crashing the machine or burning the
hardware.

The kernel's purpose in life should be to enable userspace to do things.

You make things too hard for people to do stuff via the kernel and you
end up with the kernel being out of a job.  People either implement
things entirely in userspace (userspace tcp stacks on raw sockets or
tap or udp) or switch to a different kernel or create a local fork...

I'm not saying the proposed solution is ideal (although honestly it
doesn't seem bad), but this problem does deserve a clean *kernel*
solution instead of insane userspace hacks or non vanilla Linux
patches which then propagate to a billion devices...
--
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