ubuntu-webapps template needs access to SignonUi API

From irc:
10:07 < jdstrand> mardy: thanks. so, does this mean that the facebook app can get the twitter app's cookies?
10:08 < jdstrand> mardy: how do the signon cookies relate to the browser cookies, if at all?

1) Yes, the process running the facebook webapp could get the cookies for the twitter account. However, the code to do this D-Bus call is part of the webapp-container, and is not accessible to the webapp (Alex, correct me if I'm wrong). If this is not true or not totally reassuring, we can add an access control check in the SignonUi implementation of the API, so that it checks whether the caller has been granted access to the account.

2) They are the cookies stored by the WebView invoked during the creation (or re-authentication) of the account. They are browser cookies at all effects, and we are copying them to the webapp's WebView before opening the webapp's URL, so that the webapp will be already logged in (this of course won't work if the cookies are expired, but it helps reducing the authentication requests).

We talked about this on IRC. Here is the breakdown:
 * when user adds an account to online accounts, the online accounts session gets a cookie from the site and stores it in a cookie jar specific to this account
 * when a webapp asks to use the account, online accounts will prompt the user for access (when bug #1230091 is fixed)
 * if the user says 'yes, this webapp can use this online account', only then will the webapp-container use cookiesForIdentity to grab the cookies and prepopulate the webapp's cookie jar with the cookies online accounts has for this site

This is all fine. The question then becomes, can a malicious site attack the webapp-container or Unity APIs that are exposed to webapps to use cookiesForIdentity on other accounts that the user has setup but not authorized the access to (eg, badbook requests access to facebook, the user says 'ok', and badbook tries to get the cookies for twitter). At this point, there is no API for a malicious app to use so the malicious app would have to exploit a vulnerability in the webapp-container or webapp APIs. As such, I will add the access to the ubuntu-webapp template, but I think it would be a useful hardening measure to add an ACL check to the SignonUi implementation of the API , so that it checks whether the caller has been granted access to the account. (as Alberto mentioned).

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

---------------
apparmor-easyprof-ubuntu (1.1.4) trusty; urgency=medium

  * 1.*/ubuntu-sdk: adjust for ubuntu-html5-app-launcher (LP: #1274640)
    - allow reexec for /usr/bin/ubuntu-html5-app-launcher to handle HTML5 apps
      launched via upstart-app-launch
    - allow read access to /usr/share/ubuntu-html5-app-launcher/**
  * 1.*/accounts:
    - allow read on @{HOME}/.local/share/accounts/** to dereference click
      symlinks for online accounts providers (LP: #1278859)
    - add comment about usage of com.nokia.singlesignonui.cookiesForIdentity
  * 1.*/networking: finetune DownloadManager DBus access (LP: #1277578)
    - explicitly allow safe and explicitly disallow unsafe DownloadManager
      APIs
    - restrict apps to their own downloads
  * 1.*/ubuntu-webapp: allow the webapps access to SignonUi API for retrieving
    web cookies for an account (com.nokia.singlesignonui.cookiesForIdentity).
    This is being added to the ubuntu-webapp template instead of the accounts
    policy group because this API should only be available to the webapp
    container and is not needed to use online accounts in general
    (LP: #1278934)
 -- Jamie Strandboge <email address hidden> Wed, 12 Feb 2014 09:20:58 -0600

FYI, filed bug #1279786 to request adding ACL checks for cookiesForIdentity.