netdev - Re: [PATCH 2/2] mac80211_hwsim: Allow managing radios from non-initial namespaces

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: <1462779045.30690.2.camel@sipsolutions.net>
Date:	Mon, 09 May 2016 09:30:45 +0200
From:	Johannes Berg <johannes@...solutions.net>
To:	Martin Willi <martin@...ongswan.org>
Cc:	linux-wireless@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH 2/2] mac80211_hwsim: Allow managing radios from
 non-initial namespaces

On Wed, 2016-05-04 at 10:33 +0200, Martin Willi wrote:

> > This changes today's default behaviour of moving the wiphys to the
> > default namespace. Did you intend to destroy them based on the
> > netgroup, i.e. based on the namespace that created them? Actually,
> > maybe they should move back to the namespace that created them, if
> > the namespace they are in is destroyed? But that's difficult, I
> > don't
> > mind this behaviour, but I'm not sure it's what we want by default
> > for radios created in the init_net.
> With the proposed approach I destroy all radios if the owning
> namespace gets deleted, because we probably don't want them landing
> in init_net if they are created from a (unprivileged) userns process.

I agree they shouldn't land in init_net.

> I think this is what other "virtual" interfaces do (gre tunnels, veth
> etc.). If we think of hwsim radios as such a "virtual" device, that
> makes IMO sense to delete them.

Ok, I have no idea what happens there.

> If we want to keep the existing behavior, we could move radios
> belonging to the init_net-associated netgroup back to init_net, that
> shouldn't be too difficult.
> 
> Moving the radio back to the creators namespace would be the most
> consistent behavior, so I'll check how difficult such a reverse
> lookup is. We then would delete the radio only if it is in the
> creators namespace, or if the creators namespace is gone. Does that
> make sense?

It does make sense, but it does also feel a bit complicated. Perhaps
just special-case the init_net case for consistency with the existing
behaviour, and reserve netgroup 0 for that so we can easily check for
it?

johannes