Snap security questions

[espy]

On 02/01/2017 09:46 AM, Jamie Strandboge wrote:
> On Wed, 2017-02-01 at 20:33 +0800, James Henstridge wrote:
>> Hi,

[...]

>> 3. QNetworkAccessManager wants to access NetworkManager
>>
>> We use QNetworkAccessManager as our HTTP library.  This results in a
>> number of denials for D-Bus method calls to NetworkManager.
>>
>> I can make these denials go away by plugging in to the
>> ":network-manager" slot, but a quick look at that interface shows that
>> it grants a lot more permissions than I need or want (i.e. permission
>> to reconfigure the network).
>>
>> I imagine that a lot of snaps will use QNetworkAccessManager, so it
>> would be nice if the calls it makes were allowed by some
>> auto-connectable interface.  If not as part of ":network", then
>> something similar.
>
> The network-manager API is highly privileged (and messy) and should not be auto-
> connected. Most applications that use network manager are only trying to figure
> out if they are online or not, but the way to do that in the network manager API
> is to query a ton of things a confined app shouldn't typically have. This is
> what Qt does by default and this is why the connectivity-api was developed and
> used on Touch[1]. connectivity-api is proxy that can answer questions like "am I
> online" on behalf of the application. On Touch, iirc, Qt was modified to use
> connectivity-api so Touch apps transparently used connectivity-api behind the
> scenes.

AFAIK, the Touch version of Qt was never modified to use the 
connectivity-api (which is part of indicator-network), as the API was 
never fully fleshed out.  It really only offered two public properties 
'Status' ( Offline | Connecting | Online ) and a boolean flag which 
indicated whether or not the connection was bandwidth-limited.

As such, it really wasn't enough to support the internal Qt network 
Bearer API.

> AIUI, the Personal team is in the process of creating the connectivity-
> api snap and I suspect this'll work when using ubuntu-platform content snap
> (Personal team, please correct me if I mispoke). Once connectivity-api works as
> a snap, the plan is to make the connectivity-api accesses in an interface that
> is auto-connectable (you might check with the Personal team on the status of all
> this connectivity-api work).

Interesting...  Anyone from the Personal team care to comment on the 
status of this work?  Has any work gone into re-working the original API?

Regards,
/tony