Re: NM 0.9 asks for PK auth without need



On Tue, 2011-10-11 at 16:23 +0200, Ludwig Nussel wrote:
> Dan Williams wrote:
> > On Fri, 2011-10-07 at 15:43 +0200, Ludwig Nussel wrote:
> > > Ludwig Nussel wrote:
> > > > 802.11x connections that are configured to always prompt for the
> > > > password also always require polkit authentication (bgo#646187).
> > 
> > So the PK stuff is a mix of permissions and historic configuration.
> > First off, network configuration is potentially a privileged operation
> > since you have a lot of power to screw up the machine.
> > 
> > But storing your WPA PSK in your user session doesn't make a ton of
> > sense since it's required by everyone who connects to the network. In
> > contrast to a VPN password or a EAP password, which are specific to your
> > user, not to the machine (typically).  Windows and Mac OS X both make
> > WiFi PSK networks system-wide, so NM's previous behavior also didn't
> > match up with common expectations.
> 
> ACK
> 
> > So when creating a new wifi network, you first need to authenticate to
> > create the network in the first place.  That gets creating without the
> > PSK since the applet doesn't necessarily want to include a ton of
> > complex code that checks what specific passwords might be required.
> > Instead, it waits for NM to ask the applet what is required.  Then the
> > applet throws up a dialog, but since users want to see any old passwords
> > (since this case is no different than the "password is wrong" case)
> > another request is triggered to read the secrets so we can populate the
> > UI with the old key.  Of course it's a new network, so that key isn't
> > there yet.  But there's no way to know that without requesting it,
> > really.
> 
> Yes, I got that. It's fine that nm-applet doesn't make a difference
> and just implements generic prompts for simplicity. The problem with
> the polkit popup when asking for a 802.11x password for an existing
> connection first and foremost really is just a bug of
> has_system_secrets(). The patch I sent tries to fix that.
> 
> > Obviously the secret could be stored in the user session and be visible
> > to the creating user only; but that kills the feature of system-wide
> > connections by default, which should be doing for most network types
> > (excluding VPN and possibly 3G).  That's essentially what 0.8 and
> > earlier did, and we had reasonable requests to change that.
> 
> The way NM 0.9 treats all connections as system connections is fine
> in principle AFAICT. It just needs some fine tuning to prompt for PK
> auth in the right moments IMO. Granting users privileges to edit
> connections by default is not the solution.
> 
> > There are probably ways to reduce the PK spammage, and I hope there are,
> > and I'm very interested in figuring out how we can do that.  But this
> > also could be handled better at the PolicyKit level; perhaps we should
> > simply default to auth_admin_keep or auth_self_keep?  That should kill
> > the need for the second dialog, I think.  Does that make a difference in
> > the usability?
> 
> You already rely on _keep when configuring new connections. Ie
> 
> 1. user clicks on ESSID he wants to connect to
> 2. nm-applet shows the new connection edit dialog and posts results to NM
> 3. NM asks PK for auth
> 4. NM creates the new connection without secrets and stores it in /etc
> 5. NM starts the connection and detects missing secrets
> 6. NM asks PK for auth to determine whether it's allowed to send
>    existing system secrets to nm-applet
> 7. NM asks nm-applet to prompt for secrets
> 8. nm-applet sends secrets back to NM
> 9. NM checks whether the auth at 6 was fine to determine whether to
>    actually use the secrets the user sent.
> 
> That could be further improved IMO.
> 
> By exchanging 2 and 3 the users that are not allowed to administer
> their machine would not even try to start setting up connections.

I tried to think of how this would happen but didn't get there.  Did you
have any implementation thoughts here?  Ideally the applets wouldn't
even let you do this (since they can ask whether they are allowed to
perform the action too) since it's pointless to present choices to the
user that are just going to be denied by NM.

> 6 could be skipped because the user is already authenticated by 3
> so you would not rely on PK's _keep.

But I thought that's what _keep did for us already?  Basically, we still
need to check authorization in NM, and I had assumed use of _keep would
simply return "success" since PK should be tracking whether the user is
authorized and for how long.  Would be somewhat odd if PK didnt' do this
for us.  Unless we're not requesting the same permission in (3) and (6)?
I didn't go check the code, but I *thought* it was still the same
permission there, and thus that PK would simply return "authorized" for
(6) because the user had already authenticated, and we specified _keep.

> To achieve that NM could store an extra key with the connection that
> indicates that the connection is still incomplete and missing pieces
> are supposed to be filled in by user XY.

Well, we could use timestamp for this; NM tracks that in a lookaside
file, and if the connection has never been successfully used, the
timestamp will be 0.  These days NM keeps the timestamp separate from
the connection data, so we're guaranteed that timestamp will be updated.
That didn't used to be the case for 0.8 and earlier.  I'm not sure we
need to track which user created it since PK should be handling the
authentication for us if we use _keep.  AFAIUI.

> Alternatively NM could use a special virtual connection (like the
> "auto eth*" connections) during setup phase. When the connection is
> successful it could convert it into a real one and actually save in
> /etc only then¹.
> 
> Wrt wrong-password-dialogs you could avoid surprising PK popups by
> showing the dialog in a read only view with an unlock button first.

Yeah, I'd thought about this when implementing this stuff.  At least in
nm-applet we could do that, and I'd be interested in a patch for it.  ie
leave the secrets blank and only if the unlock button got clicked, like
you suggest, fill in the entry with existing secrets.  So we wouldn't
need to do read-only, but jsut dont' request existing secrets (and thus
don't trigger a PK request) until the unlock button got clicked.

But still, I'd think PK would handle the second request for us since the
user already authenticated to add the connection in the first place...?
And I thought the permissions were the same for the add connection and
the get secrets requests (ie, modify.system).

Dan

> Those popups are surprising because they are shown before the user
> actually knows what the authentication is for.
> However, even better might be to just avoid wrong-password-dialogs in
> the first place. Just fail the connection.
> 
> cu
> Ludwig
> 
> [1] That way of implementing it would probably also allow to probe
> for other things, like e.g. IPv6 connectivity. Ie if there was no
> IPv6 prefix announcement during setup NM doesn't need to wait for
> one later either and therefore set the option to ignore v6.
> 




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]