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
| ||
|
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