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:	Tue, 29 Oct 2013 00:48:42 +0100
From:	Hannes Frederic Sowa <hannes@...essinduktion.org>
To:	Dan Williams <dcbw@...hat.com>
Cc:	David Miller <davem@...emloft.net>, 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

On Mon, Oct 28, 2013 at 06:16:19PM -0500, Dan Williams wrote:
> On Mon, 2013-10-28 at 17:17 -0400, David Miller wrote:
> > 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.
> 
> Honestly, I'd be completely happy to leave temporary address handling up
> to the kernel and *not* do it in userspace; the kernel already has all
> the code.  There are two problems with that though, (a) it's tied to
> in-kernel RA handling, and (b) it's controlled by a CONFIG option.  Both
> these are solvable.

Ah, (a) does complicate things, I agree. But the tieing is essential
currently. So it seems a netlink interface would be needed to tie a new
address to an already installed one, if the kernel should still deal
with the regeneration?

> First off, what's the reasoning behind having IPv6 privacy as a config
> option?  It's off-by-default and must be explicitly turned on, so is
> there any harm in removing the config?  Or is it just for
> smallest-kernel-ever folks?

I don't know about the policy. Does it really matter as distributions
normally switch it on? But I would not like to see the option removed
entirly, maybe the default could be changed.

> Would a new IFA_F_MANAGE_TEMP (or better name) work here, indicating
> that for some new static address, that the kernel should create and
> manage the temporary privacy addresses associated with its prefix?

But this would only be needed if they were managed in user-space, no?

Greetings,

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