Re: How to deal with unsupported wpa_supplicant parameters?

[Dan Williams <dcbw redhat com>]

On Fri, 2016-01-29 at 18:00 -0500, Eloy Paris wrote:
> Hi Dan,
>
> On Thu, Jan 28, 2016 at 12:21:24PM -0600, Dan Williams wrote:
>
> > On Thu, 2016-01-28 at 17:58 +0100, Toby wrote:
> > > I fully understand that this specific TLS1.2 issue is temporary
> > > and
> > > doesn't
> > > need to be addressed specifically. But there are many more
> > > wpa_supplicant
> > > parameters not covered by the settings spec, and there might be
> > > even
> > > more
> > > in upcoming releases. NM will always lag behind to some extend.
> > > Therefore, I'd vote for a custom settings field, which allows to
> > > specify a
> > > list of key/value pairs as a single string (based on a certain
> > > syntax), and
> > > which get's passed thru to wpa_supplicant as a sequence of
> > > parameter/value
> > > combos blindly. This would be a flexible way to address any
> > > potential
> > > future issues directly. Of course, there's no need to expose such
> > > a
> > > setting
> > > to GUIs.
> >
> > The supplicant does have a ton of options (some useful and some
> > not),
> > but punching a hole through isn't a great solution the problem at
> > hand
> > and doesn't lend itself to a great user experience, whether that's
> > a
> > GUI or a CLI.  Instead, if you think you need to customize some
> > option,
> > we'd love to hear about it so we can figure out if there is a way
> > to
> > achieve your goal using that option, or some other way.
>
> A bit of feedback from an enduser, if I may:
>
> I've also found myself in the same situation as Toby, but not with
> some
> wpa_supplicant option but with an openconnect option. I don't
> remember
> the details but as it was I could not establish an OpenConnect VPN
> connection using NetworkManager, so I had to invoke the openconnect
> binary directly, with sudo and everything.
>
> At that time I thought "it'd be nice if NetworkManager allowed me to
> plug in extra command arguments for openconnect in
> NetworkManager.conf".
>
> I think at some other time I needed to debug a DHCP problem and
> needed
> to pass special arguments to dhclient. One can create wrappers, of
> course, but I personally prefer tweaking configuration files because
> then my changes are respected and preserved by the package manager.
>
> So, I do think there is value in providing a way to pass extra
> arguments
> to the binaries that NetworkManager invokes. It should not be
> something
> that is exposed to users via user interfaces but NetworkManager
> cannot
> possibly get 100% right all the time all the options that the
> binaries
> that it spawns support and that could be helped by providing a way to
> add arbitrary arguments.

Yeah, this comes up every so often.  One big problem here is that
NetworkManager is basically a root hole, but a selective one.  It must
enforce the options that get passed to root-y things, and it must do it
well.  Especially if these are passed as command-line arguments to a
process, or if there is any possibility that the arguments will be
interpreted by a shell somewhere.  And that's not easy, and it would
mean additional restrictions on the arguments anyway.  So we'd prefer
to err on the side of caution here and enforce some sanity checking of
arguments, but that means a whitelist and what kind of argument each
one is, which is the current situation.

For plugins that use stdin or some other mechanism (like vpnc) this
isn't an issue.  Nor is this an issue for wpa_supplicant because the
network config is passed with D-Bus.  But for openvpn and others like
openswan/libreswan, it definitely is.

Dan

> Anyway, I do love NetworkManager, and thank all of you for all the
> work
> you put into it.
>
> Cheers,
>
> Eloy Paris.-
>
>
> > As I said before, I don't think this warrants a new NMSetting
> > property,
> > but clearly there is need for a different workaround for the TLS
> > v1.2
> > case.
> >
> > Dan
> >
> > > I had been hoping for such a feature to exist without being
> > > documented (as
> > > it would be one of the first things I'd implement), but it looks
> > > like
> > > this
> > > is not the case.
> > > Toby
> > > Am 28.01.2016 17:25 schrieb "Dan Williams" <dcbw redhat com>:
> > >
> > > > On Thu, 2016-01-28 at 09:50 +0100, Toby wrote:
> > > > > Hi,
> > > > > due to a delay in the upgrade of our corporate radius
> > > > > servers, I
> > > > > temporarily need to deactivate TLSv1.2 in phase1 of WPA2/EAP
> > > > > -PEAP, to
> > > > > bypass a conflict with wpa_supplicant >=2.4. (known issue)
> > > > > In wpa_supplicant.conf this would require a parameter
> > > > > phase="tls_disable_tlsv1_2=0".
> > > > > But this parameter is not covered by the current settings
> > > > > spec,
> > > > > correct?
> > > > > How to deal with this situation?
> > > > > Is there a way to extend a profile with arbitrary
> > > > > wpa_supplicant
> > > > > parameters?
> > > > > Or can I merge stuff from wpa_supplicant.conf with settings
> > > > > transferred via
> > > > > DBUS?
> > > > > Or is excluding this WiFi network from being managed by NM
> > > > > the
> > > > > only
> > > > > valid
> > > > > solution?
> > > >
> > > > Currently, exclusion or downgrading the supplicant to a version
> > > > that
> > > > does not advertise TLS v1.2 support (eg, downgrade to <= 2.3)
> > > > are
> > > > the
> > > > solutions.  I don't think we want to add a setting property for
> > > > this
> > > > since it will eventually no longer be required, but perhaps a
> > > > config
> > > > file parameter or some other out-of-band mechanism to disable
> > > > TLS
> > > > v1.2
> > > > where needed would be acceptable, and that can be dropped at a
> > > > future
> > > > date when this is no longer a problem.
> > > >
> > > > Dan