ubuntu-phone team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxxxxx>]

On 09/18/2013 03:24 PM, Tony Espy wrote:
> On 09/17/2013 06:33 PM, Jamie Strandboge wrote:
>> On 09/12/2013 05:21 PM, Jamie Strandboge wrote:
>>> On 08/01/2013 08:23 AM, Jamie Strandboge wrote:
>>>> On 08/01/2013 05:23 AM, Iain Lane wrote:
>>>>> On Wed, Jul 31, 2013 at 05:42:43PM +0100, Iain Lane wrote:
>>>>>> On Wed, Jul 31, 2013 at 03:18:27PM +0400, Alberto Mardegan wrote:
>>>>>>> On 07/30/2013 07:50 PM, Iain Lane wrote:
> 
> <SNIP>
> 
>>>> Along these lines-- we really need to define and document the canonical way for
>>>> determining network accessibility. My team is tasked with defining apparmor
>>>> policy for this, and SDK app developers should ideally do this one way and then
>>>> my team can write tests to make sure that it works for that use case. Everyone
>>>> coming up with their own method won't work with application confinement.
>>>>
>>> I looked into this a bit today. We should *not* rely on anything that uses
>>> network-manager to obtain this information. Its DBus API does not currently
>>> provide the answer to "Can I use the internet?" without granting a whole bunch
>>> of other accesses.
> 
> So it seems like we're stuck, we can't easily use NM without granting too much
> access, and we can't use qtdeclaritive5-systeminfo-plugin because it requires
> opening up the ofono DBus APIs, potentially revealing too much information.
> 
> Sounds like a bit of a catch-22 to me.
> 
> That said, I'm leery about your suggestion to provide a new DBus service in
> order to provide this information to the app framework.  Although it seems like
> a simple concept, it'd be yet another daemon running on the system who's purpose
> is to proxy information available from another system daemon ( or daemons ).  NM
> should have the information and the means to acess the information.  I woudl
> think we'd be able to fix what really sounds to me like an access control problem.
> 
> Looking at your description in LP: #1226844 it seems that AppArmor allows access
> control at the DBus interface member ( ie. method name ) level.  Wouldn't it be
> possible to open up the required NM methods for qtdeclaritive5-systeminfo-plugin
> to be able to determine online state, active interface, ...?
> 
> Note, you didn't actually say however that qtdeclaritive5-systeminfo-plugin has
> code to talk to NM, so there's a chance that this code would need to be written.
> 
It will talk to network-manager, but it needs wide permissions which reveal too
much information (it will drill down far into the API which exposes MAC
addresses, SSIDs, etc to apps). I tried giving only what made sense, but
qtdeclaritive5-systeminfo-plugin didn't work right if it got some info from
network-manager, but not all.

>>> Instead, apps should use qtdeclarative5-systeminfo-plugin, specifically
>>> NetworkInfo[1]. I played with this today and rather than talking to
>>> network-manager, it just reads various files in /sys, /proc and needs 'inet
>>> stream' and 'inet dgram'. I'll be updating the apparmor policy group for
>>> 'connectivity' to allow these accesses so it works with
>>> qtdeclarative5-systeminfo-plugin. I also tested (a bit) with C++ using
>>> QHostAddress and QNetworkInterface.
> 
> Hmmm, so for some things the plugin goes to /proc and /sys, and for others it
> bails and uses a DBus API.  I would think we'd be better off having it querying
> a single source (NM in this case).
> 

This is being discussed in LP: #1226844. It seems that on mako, /proc and /sys
don't have what qtsystems-opensource-src can use, which is why it goes to ofono.
Fix that and we can avoid ofono.

Well, either we have a very small service that can query network-manager for if
we're offline, online, online-expensive and qtsystems-opensource-src uses that
or we adjust network-manager to provide that API and qtsystems-opensource-src
can just use that. If adjusting network-manager is better-- that's fine (if it
had a reasonable API for detecting online connectivity, we can limit apps to
just that rather than exposing all kinds of sensitive information (like you said)).

-- 
Jamie Strandboge                 http://www.ubuntu.com/

Attachment: signature.asc
Description: OpenPGP digital signature