netdev - Re: dhcp client packet sniffing...

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100408114738.GA23329@gondor.apana.org.au>
Date:	Thu, 8 Apr 2010 19:47:38 +0800
From:	Herbert Xu <herbert@...dor.apana.org.au>
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org
Subject: Re: dhcp client packet sniffing...

On Thu, Apr 08, 2010 at 03:50:49AM -0700, David Miller wrote:
> 
> This is an old topic, but looking at traces tonight I was reminded
> about it.
> 
> dhcp clients sniff every packet in the system, the reason it does this
> and the things we can do to make it not have to do so have been
> discussed before.  Actually, I don't remember where we got with
> that and if we were able to make it such that the dhcp client
> doesn't have to do this any more.  Herbert?

The main problem is that it needs to be able to receive packets
destined to an address which is not yet a local address.  IOW,
it needs to be able to bypass the routing table and receive
non-local traffic.

> This means every packet in the machine gets sniffed.
> 
> The DHCP client at least installs a socket filter that only accepts
> the packets that the DHCP client is actually interested in.
> 
> The problem is that we clone the SKB and do some other operations
> before running the socket filter.
> 
> I was thinking, what if we simply move the sk_filter() call up to
> dev_queue_xmit_nit()?  And if sk_filter() rejects we don't even need
> to clone the packet.

Since you're talking about dev_queue_xmit_nit, I presume you're
mainly concerned about the TX direction?

FWIW the DHCP client does not need to see any packets in the TX
direction.  So if we could provide a way to only sniff RX traffic
then that would remove the need to clone for TX.  However, this
may require user-space modifications.

Another approach is to use skb_share.  At some point all protocols
were designed to handle shared skbs.

If we could tap into that then it would be an obvious way to
eliminate the clone.  To do this we'd need to audit all the
protocols to ensure that they can still handle shared packets
safely.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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