netdev - Re: [PATCH iproute2] ss: Include -E option for socket destroy events

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] [day] [month] [year] [list]

Date:	Tue, 16 Jun 2015 16:17:18 -0400
From:	Craig Gallek <kraig@...gle.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	netdev@...r.kernel.org,
	Stephen Hemminger <stephen@...workplumber.org>,
	Eric Dumazet <edumazet@...gle.com>
Subject: Re: [PATCH iproute2] ss: Include -E option for socket destroy events

> I am not sure filter works, and apparently some fields are not properly
> reported ? (source port for example looks wrong)
>
> (Note : you probably need to filter in user space, but ss should already
> have support for this)
Ah, good catch on the filter.  It can be fixed by
- if ((err = inet_show_sock(h, NULL, diag_arg->protocol)) < 0)
+ if ((err = inet_show_sock(h, diag_arg->f, diag_arg->protocol)) < 0)
in show_one_inet_sock.  I believe this worked previously because the
filter determined the parameters of the netlink request, effectively
causing the filtering to happen in the kernel.  However, if the
ssfilter defined a parameter that could not be used select sockets via
the netlink request (either because it is a concept not available in
the request structure or because the multicast groups have no request
concept), this user space filtering parameter would be necessary.
Perhaps this was an optimization to not do userspace filtering when we
know we won't need it?  In that case, my updated version of this patch
should probably set the filter parameter of inet_diag_arg to NULL in
the case of a get request and to the actual userspace filter in the
case of monitoring the broadcast data.

The source port issue is a harder problem (related to the kernel
patches, not this one).  The point at which socket information is
broadcast happens after the unhash callback of the appropriate
protocol (called in sk_common_release).  This process sets the source
port of the socket to zero (via __inet_put_port for tcp and
udp_lib_unhash for udp).  If we want the source port to be returned, I
believe the only options are broadcasting earlier in the destruction
path (potentially missing any activity that may happen after that
point) or to store the source port in an additional location for later
use...
--
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