The Device.Control action is configured as:
  <allow_active>auth_self_keep</allow_active>

Which means that the user's password will indeed be requested when unlocking the device. We could change that to 'yes', allowing the user to send the PIN to the device without requesting password, but that could potentially harm if e.g. a user takes the already logged in system and just sends random PINs to the modem, which will end up blocking the SIM.

But I'm not a polkit user myself, so not sure what to say.

I assume not building polkit support would be the same as allowing everything?

(In reply to comment #2)
> I assume not building polkit support would be the same as allowing everything?

Yeah.

BTW, I just checked and I'm indeed using --with-polkit by default... good to know.

Maybe you could add an option to configure that sets a permissive default policy, similar to what NetworkManager has?

Dan, what do you think?

Is it worth adding a new configure parameter to make the Modem.Control interface have a 'yes' policy for the active user? Or just add 'yes' my default?

BTW, I'm curious about which distros choose to have --enable-modify-system in NetworkManager and which ones do not.

And what about the rest of the auth_self_keep actions?

org.freedesktop.ModemManager1.Contacts
org.freedesktop.ModemManager1.Messaging
org.freedesktop.ModemManager1.Location

I think accessing contacts, SMS and GPS is also something the typical user would want to do without authenticating again.

(In reply to comment #6)
> And what about the rest of the auth_self_keep actions?
> 
> org.freedesktop.ModemManager1.Contacts
> org.freedesktop.ModemManager1.Messaging
> org.freedesktop.ModemManager1.Location
> 
> I think accessing contacts, SMS and GPS is also something the typical user
> would want to do without authenticating again.

Yeah, actually USSD has already 'yes', so we could also set it for those. I guess that if NM already allows (can allow via configure) the current user to modify system connections we should also allow that. And our side is even less critical I would say, as it is not changing 'auth_admin_keep'->'yes', but 'auth_self_keep'->'yes' instead.

I pushed a new 'aleksander/polkit-updates' branch to MM git, with the following changes:

 * Renamed configure switch from '--with-polkit' to '--enable-polkit' and make it 'auto' (i.e. enable polkit automatically if polkit headers are found). This is to make it equivalent to what NM currently has.

 * Defaulted Messaging, Location and Contacts interfaces to 'yes' policy, i.e. allow the current user to access them without explicitly re-authenticating.

 * New '--enable-user-control-modem' configure switch, which makes the Modem.Control policy be 'yes' instead of 'auth_self_keep', allowing the user to control the modem without explicitly re-authenticating.

Comments?

Haven't actually tried building it, but looks great to me.

I don't mind having a permissive policy at configure time like NM has.  The questions we have to answer are:

What operations should a user be able to perform without a password?

For any operations *not* on that list, we then decide whether the user needs to enter their password (auth_self), which isn't secure, but simply proves there's a human at the machine and not a script of some sort.

Or should that operation require the root password, implying that it's something that could damage the hardware or compromise the machine?

Sending the PIN code can block the SIM, and then sending the PUK 10 times can render the SIM inoperative.  So if you want, you can ruin somebody's SIM pretty quickly, which was one reason unlocking the device required authentication.

(Many desktop environments will offer to remember your passwords in a keychain, and will unlock that keychain automatically when you log in, which means you won't be asked for your password.  Does your DE do that?)

In the end, it's really up to the packager/builder to select the security profile they want, and hopefully they are fully aware of the risks involved.  MM should provide the tools to enable lockdown and protected operations, but leave some of these policy decisions to the user.  The configure-time "permissive" policy is something that NM did to make it slightly less annoying, otherwise you either turn all protections off, or you have to learn how to configure PolicyKit.

Reviews on aleksander/polkit-updates...

> build: new '--enable-user-control-modem' configure switch

Any reason not to just do permissive/strict/etc for configure?  What we're doing here is really making mutually exclusive policykit default profiles as a convenience.  But --enable-user-control-modem is really a feature, and logically we could add more configure-time options like this, but it's not mutually exclusive.  Basically, I think we should have one or more "default profiles" that the builder can choose from, and I think it makes sense to have them specified as part of the PolicyKit setup like --with-polkit=permissive or --with-polkit=strict.  (I don't care whether it's --enable-polkit or --with-polkit though).

> policy: don't require to re-authenticate the user in non-control operations

Changes are fine, but commit message is a bit misleading.  If we change to "yes", the user never has to authenticate, so "re-auth" here isn't quite right.  Also, best to say "active" user instead of "current", since "active" means the one whos actually controlling the machine right now from a monitor, while "current" could be anyone logged in.

Also, just as an aside, one reason the Location API was locked was that mobile devices often request your permission before letting any program look at your location.  Changing this to "yes" allows that, without any notification to the user, so any program could now monitor your location.  Also, any program could now grab all your SIM contacts and text-message something to your entire contact list.

What we really need here is some kinda of permissions framework that doesn't necessarily request a password, but just this-thing-asks-for-permission, Allow/Deny.  Except that's like the Windows UAC thing, and that's something that nobody wants because it trains you to just click Allow :(  We need a more through review of how this is all supposed to work without exposing you to charges or privacy issues.

(In reply to comment #10)
> (Many desktop environments will offer to remember your passwords in a keychain,
> and will unlock that keychain automatically when you log in, which means you
> won't be asked for your password.  Does your DE do that?)

Aleksander points out that I'm wrong here, this is keyring and PolicyKit doesn't interact with it by design (PK wants to prove you're human, so caching passwords on login would be counter-productive), so ignore this.

Created attachment 246432 [details] [review]
Patch to add 'strict' and 'permissive' policies

The following patch allows --with-polkit to be specified either with 'permissive' or 'strict'. When configured to use permissive policies, active user won't be requested password when controlling the modem or other feature interface (e.g. messaging). When configured to use strict policies, password will be requested.

Note that still, we suggest to use 'strict' policies, and let the UI request passwords when needed, if ever.

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.