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:	Wed, 16 Dec 2015 07:43:34 -0800
From:	Stephen Hemminger <stephen@...workplumber.org>
To:	Lorenzo Colitti <lorenzo@...gle.com>
Cc:	netdev@...r.kernel.org, davem@...emloft.net,
	hannes@...essinduktion.org, eric.dumazet@...il.com, ek@...gle.com,
	tom@...bertland.com, zenczykowski@...il.com
Subject: Re: [PATCH v7 0/4] Support administratively closing application
 sockets

On Wed, 16 Dec 2015 12:30:01 +0900
Lorenzo Colitti <lorenzo@...gle.com> wrote:

> This patchset adds the ability to administratively close a socket
> without any action from the process owning the socket or the
> socket protocol.
> 
> It implements this by adding a new diag_destroy function pointer
> to struct proto. In-kernel callers can access this functionality
> directly by calling sk->sk_prot->diag_destroy(sk, err).
> 
> It also exposes this functionality to userspace via a new
> SOCK_DESTROY operation in the NETLINK_SOCK_DIAG sockets. This
> allows a privileged userspace process, such as a connection
> manager or system administration tool, to close sockets belonging
> to other apps when the network they were established on has
> disconnected. It is needed on laptops and mobile hosts to ensure
> that network switches / disconnects do not result in applications
> being blocked for long periods of time (minutes) in read or
> connect calls on TCP sockets that will never succeed because the
> IP address they are bound to is no longer on the system. Closing
> the sockets causes these calls to fail fast and allows the apps
> to reconnect on another network.
> 
> Userspace intervention is necessary because in many cases the
> kernel does not have enough information to know that a connection
> is now inoperable. The kernel can know if a packet can't be
> routed, but in general it won't know if a TCP connection is stuck
> because it is now routed to a network where its source address is
> no longer valid [5][6].


I see no security checks in the diag infrastructure.
Up until now diag has been read-only access and therefore has been
allowed for all users.
--
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

Powered by blists - more mailing lists