netdev - Re: [PATCH 1/4] ipv4: add option to drop unicast encapsulated in L2 multicast

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: <alpine.LFD.2.11.1504111305440.2449@ja.home.ssi.bg>
Date:	Sat, 11 Apr 2015 13:39:05 +0300 (EEST)
From:	Julian Anastasov <ja@....bg>
To:	Johannes Berg <johannes@...solutions.net>
cc:	netdev@...r.kernel.org, linux-wireless@...r.kernel.org,
	matti.gottlieb@...el.com
Subject: Re: [PATCH 1/4] ipv4: add option to drop unicast encapsulated in L2
 multicast


	Hello,

On Fri, 10 Apr 2015, Johannes Berg wrote:

> > - no way to select correct skb->pkt_type in inet_rtm_getroute
> > before ip_route_input, this is a chiken-egg problem, of course,
> > skb->pkt_type = PACKET_HOST can work for now
> 
> This is interesting. Why does that even build an skb and route it, if it
> really just cares about the struct rtable? Anyway, you're right, using
> PACKET_HOST would work. I'm not really sure I see the chicken-and-egg
> problem though, it's not like the result of this is used to route the
> skb again or something, afaict?

	If we want to set correct pkt_type here we should
know the type of daddr (multicast => PACKET_MULTICAST,
broadcast => PACKET_BROADCAST, etc) and we can know it only
after routing (rt_type). I hope we will not do other checks
with pkt_type, so we can put some comment that
skb->pkt_type = PACKET_HOST is just to make
DROP_UNICAST_IN_L2_MULTICAST check happy.

> > - ip_route_input is called also for ARP, so incoming ARP
> > broadcasts are not replied anymore
> 
> Hm. I didn't see this in my testing so far, but I only enable this
> temporarily, so perhaps by that time it was already done.

	I didn't tested it myself, may be you can try:

other_host_on_LAN# arp -d patched_box
other_host_on_LAN# arping -c 1 -I eth0 patched_box

	There must be reply for broadcast requests.

> This looks like another case of using this function to not really route
> anything but to just look up the route, similar to the
> inet_rtm_getroute() function you pointed out. Perhaps that would warrant
> splitting out somewhat.

	Yes, ARP essentially performs rp_filter check (note
that arp_filter check is limited only to local targets, not
to proxy_arp) and target address type check.

	The solution would be to add skb->protocol == htons(ETH_P_IP)
check.

> On the other hand, there's not all that much reason not to put this into
> ip_rcv_finish(), we already touch the rt->rt_type there for MIB
> counters. I'll look into that.

	May be in ip_local_deliver_finish because:

- ip_forward() already has PACKET_HOST check.

- for broadcast/multicast dests we do not care

- CLUSTERIP works in LOCAL_IN (after ip_rcv_finish), LOCAL_IN
is here: ip_rcv_finish->dst_input->ip_local_deliver->
ip_local_deliver_finish

Regards

--
Julian Anastasov <ja@....bg>
--
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