Online detection does not work with confined apps on Nexus 4

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.

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

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).

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.

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?

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.

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.

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.

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.

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.

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?

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 :-)

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...

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.

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".

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

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.

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

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

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

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

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

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

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

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

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

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