netdev - Re: [patch net-next] ipv6: allow userspace to create address with IFLA_F

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:	Mon, 28 Oct 2013 17:17:25 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	hannes@...essinduktion.org
Cc:	jiri@...nulli.us, vyasevich@...il.com, netdev@...r.kernel.org,
	kuznet@....inr.ac.ru, jmorris@...ei.org, yoshfuji@...ux-ipv6.org,
	kaber@...sh.net, thaller@...hat.com, stephen@...workplumber.org
Subject: Re: [patch net-next] ipv6: allow userspace to create address with
 IFLA_F_TEMPORARY flag

From: Hannes Frederic Sowa <hannes@...essinduktion.org>
Date: Sun, 27 Oct 2013 17:48:35 +0100

> A temporary address is also bound to a non-privacy public address so
> it's lifetime is determined by its lifetime (e.g. if you switch the
> network and don't receive on-link information for that prefix any
> more). NetworkManager would have to take care about that, too. It is
> just a question of what NetworkManager wants to handle itself or lets
> the kernel handle for it.

How much really needs to be in userspace to implement RFC4941?

I don't like the idea that even for a fully up and properly
functioning link, if NetworkManager wedges then critical things like
temporary address (re-)generation, will cease.

All that seems to matter is the secret used to generate the temporary
address sequence, and perhaps things like site specific lifetime
parameters.  These are things userland can send to the kernel in
netlink messages.

Full disclosure that I am saying this from the perspective of someone
who believes that one of the biggest mistakes ever was allowing the
core of DHCP to be done in userspace.

Right now every ipv4 DHCP user ends up with their interface in
promiscuous mode.  The DHCP client implementations are huge non-
trivial bodies of code, and getting them to adopt the changes necessary
to not put the interface in promiscuous mode is harder than pulling
teeth.

If at least the DHCP protocol communications part were in the kernel,
on the other hand, we could remove the problem quite swiftly.

This problem has existed for more than a decade, btw.  There simply
exists no will to fix it properly, even after all this time, because
breaking the ice on those DHCP client code bases in userbase is hard.

So I want to see less fundamental stuff about interface configuration
and address assignment in userland, not more.
--
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