consider shipping apparmor profile for webbrowser-app

It would be nice if webbrowser-app itself could ship an apparmor profile. Since we are already confining webapps, we can leverage aa-easyprof to generate the apparmor profile. Eg, in debian/rules could have a target :

apparmor:
        aa-easyprof --policy-version=1.2 --policy-vendor=ubuntu \
        -t ubuntu-webapp \
        --policy-groups=accounts,audio,content_exchange,content_exchange_source,location,networking,push-notification-client,video,webview \
         --template-var="@{APP_ID_DBUS}=webbrowser_2dapp" \
         --template-var="@{APP_PKGNAME_DBUS}=webbrowser_2dapp" \
         --template-var="@{APP_PKGNAME}=webbrowser-app" \
         --template-var="@{CLICK_DIR}=/usr/share/webbrowser-app" \
         --abstraction=user-tmp \
         --read-path=/usr/share/applications/ \
         --read-path="@{HOME}/.local/share/applications/" \
         --profile-name=webbrowser-app \
         --no-verify /usr/bin/webbrowser-app | \
         grep -v CLICK_DIR | \
         sed 's/signal peer=@{APP_PKGNAME}_\*_@{APP_VERSION},/signal peer=@{APP_PKGNAME},/g' \
         > ./debian/usr.bin.webbrowser-app
         apparmor_parser -QTK ./debian/usr.bin.webbrowser-app

In this manner, you could this to update the apparmor profile:
$ debian/rules apparmor

I use '--no-verify' because we need to very lightly tidy up the profile with the 'grep -v' and the 'sed', which is why after it is cleaned I run 'apparmor_parser -QTK' on the profile to verify it. This could probably be done as part of the build too. Once the profile is in place, you can simply do something along the lines of http://bazaar.launchpad.net/~jdstrand/ubuntu-system-settings/ubuntu-system-settings-lp1296415/revision/748.

I have lightly tested this on the phone for the following:
 * http
 * https
 * sharing to messaging app
 * url-dispatcher via messaging-app to open a link (with the browser open and closed)
 * maps.google.com (prompted for access)
 * youtube (one denial: apparmor="DENIED" operation="dbus_method_call" bus="system" path="/com/canonical/Unity/Screen" interface="com.canonical.Unity.Screen" member="keepDisplayOn" mask="send" name="com.canonical.Unity.Screen" pid=12566 profile="webbrowser-app" peer_pid=1575 peer_profile="unconfined")
 * html5.grooveshark.com
 * grooveshark via music scope

I also even more lightly tested it on the desktop, and it appears to work ok.

Note: there is one denial on startup, but this is expected:
Aug 13 13:21:33 localhost dbus[10795]: apparmor="DENIED" operation="dbus_bind" bus="session" name="org.freedesktop.Application" mask="bind" pid=18407 profile="webbrowser-app"

I may be out of date on me phone (it only has promoted), but this should go away when the webbrowser-app portion of bug #1342129 is fixed.

Note2: the youtube denial will go away when oxide has media-hub integration. If we really want this profile for rtm and oxide doesn't have media-hub integration, I would need to either update aa-easyprof to allow adding dbus rules, or we can add an additional sed to add a rule for this.

Note3: instead of specifying all the command line args to aa-easyprof, we can also supply a json file for it to use.

Note4: it might be simpler to supply a easyprof json manifest file, which does the same as the above command line version. Here is an updated command to create the file, which also adds a rule for controlling the display:
apparmor:
        aa-easyprof -m ./debian/webbrowser-app-apparmor.manifest \
        --no-verify | \
        egrep -v '(# Click packages|CLICK_DIR)' | \
        sed 's/signal peer=@{APP_PKGNAME}_\*_@{APP_VERSION},/signal peer=@{APP_PKGNAME},/g' | \
        sed 's:^}: dbus (receive,send) bus=system path=/com/canonical/Unity/Screen,\n}:g' \
         > ./debian/usr.bin.webbrowser-app
         apparmor_parser -QTK ./debian/usr.bin.webbrowser-app