Online detection does not work with confined apps on Nexus 4

Bug #1341548 reported by Jamie Strandboge on 2014-07-14
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Network Menu
Fix Released
Critical
Antti Kaijanmäki
apparmor-easyprof-ubuntu (Ubuntu)
Critical
Jamie Strandboge
connectivity-api (Ubuntu)
Critical
Antti Kaijanmäki
connectivity-api (Ubuntu RTM)
Critical
Antti Kaijanmäki
indicator-network (Ubuntu)
Critical
Antti Kaijanmäki
indicator-network (Ubuntu RTM)
Critical
Antti Kaijanmäki

Bug Description

Dekko is not detecting if Online correctly. If I look at the server logs, I don't see anything in the email server logs for dekko to connect. If I look in ~/.cache/upstart/application-click-com.ubuntu.developer.dpniel.dekko_dekko_0.2.2.log, I don't see anything about connecting. If I click the globe in dekko, I see that it is in offline mode and selecting one of the others seems to make no difference (I see nothing in the server logs and the upstart logs) and the setting doesn't stick (ie, it *always* says 'Offline mode').

I thought this might be bug #1226844, but if I adjust /var/lib/apparmor/profiles/*dekko* to remove 'deny' from in front of the NetworkManager and ofono rules and run apparmor_parser -r /var/lib/apparmor/profiles/*dekko*, there are no denials but it still doesn't detect if I am online or not when on 3G.

If I get on wifi instead of 3G, dekko can detect if I am online if I apply the apparmor changes I mentioned above (though, there are still NetworkManager dbus denials).

For dekko to work as a confined application (ie, shipped in the Ubuntu App Store) it is going to need to operate without these NetworkManager and ofono DBus APIs, because they are not allowed to app store apps.

Previous description:
In addidtion to TLS on port 143, it would be nice to support imaps on port 993.

Related branches

Dan Chapman  (dpniel) wrote :

The "Force Encryption" option of the Secure Connection option selector should be defaulting to the imaps standard port 993 when selected. "No Encryption" and "Use Encryption (STARTTLS)" should default to the imap standard port 143.

When selecting "Force encryption" does it not change for you?

Obviously it can always be overridden by manually changing the port but dekko will warn you it's not a standard port for the selected protocol.

Dan Chapman  (dpniel) wrote :

Hmm maybe it won't warn you it's not a standard port, that's a bug. But it can still be overridden

Dan Chapman  (dpniel) on 2014-07-16
Changed in dekko:
status: New → Incomplete
Jamie Strandboge (jdstrand) wrote :

If I use force encyrption, the port is changed to 993. If I use STARTTLS, it is changed to 143. I can use port 993 with my current configuration with thunderbird, evolution, Mail on iOS and K9 mail.

If I look at the server logs, I don't see anything in the email server logs for dekko to connect. If I look in ~/.cache/upstart/application-click-com.ubuntu.developer.dpniel.dekko_dekko_0.2.2.log, I don't see anything about connecting. If I click the globe in dekko, I see that it is in offline mode and selecting one of the others seems to make no difference (I see nothing in the server logs and the upstart logs) and the setting doesn't stick (ie, it *always* says 'Offline mode').

So, I think the bug isn't that it doesn't support IMAPS, but that on my Nexus 4 mako device, it doesn't detect if it is online correctly. I hought this might be bug #1226844, but if I adjust /var/lib/apparmor/profiles/*dekko* to remove 'deny' from in front of the NetworkManager and ofono rules and run apparmor_parser -r /var/lib/apparmor/profiles/*dekko*, there are no denials but it still doesn't detect if I am online or not.

Note: I do see apparmor denials (grep DEN /var/log/syslog) and it looks like dekko should use the content_exchange policy group in the security manifest (adding it removes the dbus denials, but there are two others that look less important).

Jamie Strandboge (jdstrand) wrote :

Playing with this some more-- if I get on wifi instead of 3G, dekko can detect if I am online if I apply the apparmor changes I mentioned above (though, there are still NetworkManager dbus denials-- I should mention that dekko is going to need to operate without these NetworkManager and ofono DBus APIs, because they are not allowed to app store apps.

With the above, it does connect, it does prompt for the certificate, and I do see my inbox. I'll change the bug description.

summary: - please support imaps (port 993)
+ Online detection does not work with confined apps on Nexus 4
description: updated
Dan Chapman  (dpniel) on 2014-07-28
Changed in dekko:
status: Incomplete → Confirmed
importance: Undecided → Critical
assignee: nobody → Dan Chapman (dpniel)
Dan Chapman  (dpniel) wrote :

Thanks for the additional info on this.

Just to be sure I understand this correctly, confined apps in effect cannot manipulate the network session using a combo of QNetworkConfigurationManager and QNetworkSession to watch for changes in the network configuration, which i believe is where these dbus denials are coming from as it's using the bearer management api.

Dekko isn't doing anything major here regarding network session manipulation see http://bazaar.launchpad.net/~dpniel/dekko/trunk-1/view/head:/src/Imap/Model/SystemNetworkWatcher.cpp, but I can see why this isn't aloud in a confined app.

Looking at the available security profiles i see there is a 'connectivity' policy. Ideally it would be awesome to be able to determine offline, 3g/mobiledata and wifi and give the user options for setting bandwidth saving mode for mobile data connections on the fly etc...
I see there is some comments in that profile regarding the bug you mentioned previously, ( bug #1226844 ). Am I able to use this to determine the current connection/network state? Or do you know of any other way I can watch for network change events?

Jamie Strandboge (jdstrand) wrote :

Confined apps are not allowed to manipulate the network session, no. They should be able to determine whether they are online or not, and whether they are on a potentially expensive connection or not. This is currently done by looking at ofono and network-manager APIs, but allowing these to confined apps would constitute a privacy concern (ie, bug #1226844).

A new connectivity API is supposed to be implemented and the connectivity policy group will allow use of this API. This connectivity API I think is only newly implemented and I don't know if you'll have to change your code to use it or if you can continue using the API you are and the underlying system libraries will be adjusted to use the new connectivity API.

Pete Woods (pete-woods) wrote :

See this example from the connectivity API:

http://bazaar.launchpad.net/~unity-api-team/connectivity-api/trunk.14.04/view/head:/examples/example_networking_status.cpp

I am not certain if this still requires NetworkManager access, though.

Jamie Strandboge (jdstrand) wrote :

To be clear, I can allow appropriate access to NetworkManager (eg, if an NM API was added that does just the connectivity bits). The problem before was that the existing Qt/QML API that apps would use required far too much access to the NetworkManager API.

Jamie Strandboge (jdstrand) wrote :

I compiled http://bazaar.launchpad.net/~unity-api-team/connectivity-api/trunk.14.04/view/head:/examples/example_networking_status.cpp with:
$ g++ $(pkg-config --cflags connectivity-cpp NetworkManager) -std=gnu++11 ./example_networking_status.cpp -o example_networking_status $(pkg-config --libs connectivity-cpp NetworkManager)

Then tried running example_networking_status under confinement. Eg:
$ aa-exec -p <my apparmor profile> -- ./example_networking_status

I'm seeing it is using Get methods on the URFKill API, but that doesn't look safe for apps either.

Dan, I would suggest disabling this check for now until the connectivity API is worked out. I will be contacting this team to see what is going on.

Antti Kaijanmäki (kaijanmaki) wrote :

I will provide a simplified trusted helper that we can confine on dbus-level in a way that QML apps don't require access no NM directly.

Changed in indicator-network:
status: New → Triaged
importance: Undecided → Critical
assignee: nobody → Antti Kaijanmäki (kaijanmaki)
Antti Kaijanmäki (kaijanmaki) wrote :

Could you describe what parts of NM and Ofono dbus api's this app is currently trying to access, so that I can draft the necessary information to this confined dbus api?

Changed in dekko:
status: Confirmed → Incomplete
Dan Chapman  (dpniel) wrote :

Hey Antti,

At the moment dekko is using QNetworkConfiguration and QNetworkSession to determine the current network status and try and keep in sync with network dropping out and coming back up again. I had planned to re-implement this anyway, as this approach doesn't provide a way to determine cheap vs expensive connections.

The information I would like to be able to access through the Connectivity API is exactly what I see in http://bazaar.launchpad.net/~unity-api-team/connectivity-api/trunk.14.04/view/head:/examples/example_networking_status.cpp. The ability to subscribe to network status & characteristic changes.

So if you can make something available similar to the above example, that would be awesome :-)

Jamie Strandboge (jdstrand) wrote :
Download full text (3.7 KiB)

FYI, attached is the apparmor policy needed for the current implementation of the connectivity API. I compiled example_networking_status.cpp as example_networking_status.armhf, then on mako, I ran:

$ sudo apparmor_parser -r ./example_networking_status.profile && aa-exec -p example_networking_status -- ./example_networking_status.armhfSystem networking status changed to: offline
System networking status changed to: connecting
System networking status changed to: online
...

Currently there are a lot of accesses that the connectivity-api example app needs:
  # URfkill
  dbus (receive, send)
       bus=system
       path=/org/freedesktop/URfkill/*
       interface=org.freedesktop.DBus.Properties
       member={Get,PropertiesChanged},

  dbus (receive)
       bus=system
       path=/org/freedesktop/URfkill
       interface=org.freedesktop.URfkill
       member=DeviceChanged,

  dbus (receive)
       bus=system
       path=/org/freedesktop/URfkill/*
       interface=org.freedesktop.URfkill.Killswitch
       member=StateChanged,

  dbus (send)
       bus=system
       path=/org/freedesktop/URfkill
       interface=org.freedesktop.URfkill
       member=IsFlightMode,

  dbus (receive)
       bus=system
       path=/org/freedesktop/URfkill
       interface=org.freedesktop.URfkill
       member=FlightModeChanged,

  # NetworkManager
  dbus (send)
       bus=system
       path=/org/freedesktop/NetworkManager
       interface=org.freedesktop.NetworkManager
       member=GetDevices,

  dbus (send)
       bus=system
       path=/org/freedesktop/NetworkManager{,/Devices/*}
       interface=org.freedesktop.DBus.Properties
       member=Get,

  dbus (receive)
       bus=system
       path=/org/freedesktop/NetworkManager
       interface=org.freedesktop.NetworkManager
       member={PropertiesChanged,StateChanged},

  dbus (receive)
       bus=system
       path=/org/freedesktop/NetworkManager/Devices/*
       interface=org.freedesktop.NetworkManager.Device{,.*}
       member={PropertiesChanged,StateChanged},

  dbus (send)
       bus=system
       path=/org/freedesktop/NetworkManager/Devices/*
       interface=org.freedesktop.NetworkManager.Device.Wireless
       member=GetAccessPoints,

  dbus (receive)
       bus=system
       path=/org/freedesktop/NetworkManager/Devices/*
       interface=org.freedesktop.NetworkManager.Device.Wireless
       member={AccessPointAdded,AccessPointRemoved,ScanDone},

  dbus (send)
       bus=system
       path=/org/freedesktop/NetworkManager/AccessPoint/*
       interface=org.freedesktop.NetworkManager
       member=Get,

  dbus (send)
       bus=system
       path=/org/freedesktop/NetworkManager/{AccessPoint,ActiveConnection}/*
       interface=org.freedesktop.DBus.Properties
       member=Get,

  dbus (receive)
       bus=system
       path=/org/freedesktop/NetworkManager/AccessPoint/*
       interface=org.freedesktop.NetworkManager.AccessPoint
       member=PropertiesChanged,

  dbus (receive)
       bus=system
       path=/org/freedesktop/NetworkManager/ActiveConnection/*
       interface=org.freedesktop.NetworkManager.Connection.Active
       member=PropertiesChanged,

As you can see, the NetworkManager DBus API is vas...

Read more...

Jamie Strandboge (jdstrand) wrote :
Jamie Strandboge (jdstrand) wrote :

I should also not that the helper doesn't necessarily have to be a completely new daemon. It *could* be an existing one (eg NetworkManager), but the DBus connectivity API exposed by that helper would have to use a DBus path, interface and method that we could mediate on. Please talk to the security team if you are going this route.

Antti Kaijanmäki (kaijanmaki) wrote :

indicator-network will expose this API in session bus:

service name: com.ubuntu.connectivity1
object name: /com/ubuntu/connectivity1/NetworkingStatus
interface: com.ubuntu.connectivity1.NetworkingStatus

the single interface will have two standard properties "Status" and "Limitations".

Jamie Strandboge (jdstrand) wrote :

Adding apparmor-easyprof-ubuntu task. When indicator-network implements this, I will update the connectivity policy group accordingly.

Changed in apparmor-easyprof-ubuntu (Ubuntu):
assignee: nobody → Jamie Strandboge (jdstrand)
importance: Undecided → Critical
status: New → Confirmed
Jamie Strandboge (jdstrand) wrote :

Actually, I can do this now by simply using this rule:
dbus (receive, send)
      bus=session
      path=/com/ubuntu/connectivity1/NetworkingStatus,

Since the API is simple, we don't need to worry about being more fine-grained.

Antti Kaijanmäki (kaijanmaki) wrote :

yes, I plan to draft the api with confinement in mind. Each path will corresponds to individual policies/permissions.

Changed in dekko:
status: Incomplete → Confirmed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apparmor-easyprof-ubuntu - 1.2.16

---------------
apparmor-easyprof-ubuntu (1.2.16) utopic; urgency=medium

  * ubuntu/1.2/connectivity: update to use upcoming connectivity DBus API
    (LP: #1341548)
  * ubuntu/1.[12]/contacts: remove workaround policy since address-book-app
    no longer uses the telepathy API (LP: #1227818)
  * ubuntu/*: explicitly deny rw access to /dev/fb0. It is both dangerous and
    noisy with the camera app
  * ubuntu/ubuntu-webapp: receive application-specific Open on
    org.freedesktop.Application to allow url-dispatcher working with already
    running webapps (LP: #1342129)
 -- Jamie Strandboge <email address hidden> Thu, 07 Aug 2014 13:19:59 -0500

Changed in apparmor-easyprof-ubuntu (Ubuntu):
status: Confirmed → Fix Released
Changed in indicator-network:
status: Triaged → In Progress
Changed in connectivity-api (Ubuntu):
status: New → In Progress
Changed in indicator-network (Ubuntu):
status: New → In Progress
Changed in connectivity-api (Ubuntu RTM):
status: New → In Progress
Changed in indicator-network (Ubuntu RTM):
status: New → In Progress
Changed in connectivity-api (Ubuntu):
importance: Undecided → Critical
Changed in connectivity-api (Ubuntu RTM):
importance: Undecided → Critical
Changed in indicator-network (Ubuntu):
importance: Undecided → Critical
Changed in indicator-network (Ubuntu RTM):
importance: Undecided → Critical
Changed in connectivity-api (Ubuntu):
assignee: nobody → Antti Kaijanmäki (kaijanmaki)
Changed in connectivity-api (Ubuntu RTM):
assignee: nobody → Antti Kaijanmäki (kaijanmaki)
Changed in indicator-network (Ubuntu):
assignee: nobody → Antti Kaijanmäki (kaijanmaki)
Changed in indicator-network (Ubuntu RTM):
assignee: nobody → Antti Kaijanmäki (kaijanmaki)
tags: added: rtm14
tags: added: touch-2014-08-21
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package indicator-network - 0.5.1+14.10.20140820.6-0ubuntu1

---------------
indicator-network (0.5.1+14.10.20140820.6-0ubuntu1) utopic; urgency=low

  [ Ubuntu daily release ]
  * New rebuild forced

  [ Antti Kaijanmäki ]
  * Restructured the source tree to separate the different components
    better.
  * Add Connectivity Service. (LP: #1302049)
  * Connectivity Service Qt and QML bindings. (LP: #1341548)
  * Documentation for the connectivity Qt C++ and QML API Also fix
    licensing information. (LP: #1341548)
  * Move in connectivity-cpp from lp:connectivity-api. Move out
    libconnectivity-qt and qtdeclarative5-connectivity-plugin. to
    lp:connectivity-api (LP: #1341548)
 -- Ubuntu daily release <email address hidden> Wed, 20 Aug 2014 22:31:54 +0000

Changed in indicator-network (Ubuntu):
status: In Progress → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package connectivity-api - 0.0.1+14.10.20140821-0ubuntu1

---------------
connectivity-api (0.0.1+14.10.20140821-0ubuntu1) utopic; urgency=low

  [ Ubuntu daily release ]
  * New rebuild forced

  [ Antti Kaijanmäki ]
  * Move out connectivity-cpp to lp:indicator-network. Move in
    libconnectivity-qt and qtdeclarative5-connectivity-plugin.   from
    lp:indicator-network removes binary packages.   - libconnectivity-
    cpp0   - libconnectivity-cpp-dev   - libconnectivity-cpp-doc adds
    binary packages:.   - libconnectivity-qt1   - libconnectivity-qt1-
    dev   - qml-module-ubuntu-connectivity   - connectivity-doc (LP:
    #1341548)
 -- Ubuntu daily release <email address hidden> Thu, 21 Aug 2014 19:41:39 +0000

Changed in connectivity-api (Ubuntu):
status: In Progress → Fix Released
Antti Kaijanmäki (kaijanmaki) wrote :

dan, check out the new packages: libconnectivity-qt1, libconnectivity-qt1-dev, qml-module-ubuntu-connectivity and connectivity-doc.

Changed in indicator-network:
status: In Progress → Fix Released
Dan Chapman  (dpniel) on 2014-08-22
Changed in dekko:
status: Confirmed → In Progress
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package indicator-network - 0.5.1+14.10.20140826-0ubuntu1

---------------
indicator-network (0.5.1+14.10.20140826-0ubuntu1) 14.09; urgency=low

  [ Jussi Pakkanen ]
  * Exit gracefully on dbus error conditions. (LP: #1343341)
 -- Ubuntu daily release <email address hidden> Tue, 26 Aug 2014 15:04:09 +0000

Changed in indicator-network (Ubuntu RTM):
status: In Progress → Fix Released
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package connectivity-api - 0.0.1+14.10.20140826-0ubuntu1

---------------
connectivity-api (0.0.1+14.10.20140826-0ubuntu1) 14.09; urgency=low

  [ Albert Astals ]
  * Make NetworkingStatus a singleton
 -- Ubuntu daily release <email address hidden> Tue, 26 Aug 2014 17:17:00 +0000

Changed in connectivity-api (Ubuntu RTM):
status: In Progress → Fix Released
Antti Kaijanmäki (kaijanmaki) wrote :

this is *not* fixed in Ubuntu RTM. Something wrong with the Launchpad Janitor.

Changed in connectivity-api (Ubuntu RTM):
status: Fix Released → In Progress
Changed in indicator-network (Ubuntu RTM):
status: Fix Released → In Progress
Antti Kaijanmäki (kaijanmaki) wrote :

OK, seem the fixes got src-copied on archive-level

Changed in indicator-network (Ubuntu RTM):
status: In Progress → Fix Released
Changed in connectivity-api (Ubuntu RTM):
status: In Progress → Fix Released
Jamie Strandboge (jdstrand) wrote :

I tried dekko 0.2.5 on my mako on cell data and it was able to connect just fine. Thanks! :)

Dan Chapman  (dpniel) on 2014-09-29
Changed in dekko:
milestone: none → 0.3
Dan Chapman  (dpniel) on 2014-10-09
Changed in dekko:
status: In Progress → Fix Committed
Dan Chapman  (dpniel) on 2014-10-20
Changed in dekko:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers