Add Bluetooth apparmor policy

Oh, some more info:

For the device discovery, it uses the "BluetoothDeviceDiscoveryModel" [1], for sending the file it uses QBluetoothTransferManager [2], both from the Qt API

[1] http://doc.qt.io/qt-5/qml-qtbluetooth-bluetoothdiscoverymodel.html
[2] http://doc.qt.io/qt-5/qbluetoothtransfermanager.html

While in theory such a OBEX Push share plugin could be provided by the platform and hence run unconfined, both of the above mentioned APIs are useful for 3rd Party app developers to enable Bluetooth features in their Apps.

Status changed to 'Confirmed' because the bug affects multiple users.

Oh, some more info:

For the device discovery, it uses the "BluetoothDeviceDiscoveryModel" [1], for sending the file it uses QBluetoothTransferManager [2], both from the Qt API

[1] http://doc.qt.io/qt-5/qml-qtbluetooth-bluetoothdiscoverymodel.html
[2] http://doc.qt.io/qt-5/qbluetoothtransfermanager.html

While in theory such a OBEX Push share plugin could be provided by the platform and hence run unconfined, both of the above mentioned APIs are useful for 3rd Party app developers to enable Bluetooth features in their Apps.

Is there a click I can use to play with this? Will it work on mako? Do I need rc-proposed, silos, etc?

Ok, the attached .click should work on all our supported devices. You do need rc-proposed in order for receiving files to work. Sending files via content hub should work on stable too (assuming apparmor policies are in place).

Attaching another click that can establish a bluetooth connection between 2 devices. One side creates an SPP chat server, the other can connect to it as a client.

This can be used to exercise:
On the server side,
* the local Bluetooth device is made visible so that the client can scan for it
* registering a new SPP service endpoint

On the client side:
* scanning for nearby Bluetooth devices
* doing service discovery on remote devices
* connecting to the SPP server

This should work on all our supported devices too. Stable should be ok although I only really tested it on rc-proposed.

Note, I have not played with Low Energies profiles yet. So that needs to be added too but I don't have any LE devices handy right now. Will add more details when I get there.

FYI, we decided on IRC that we would add a single reserved policy group for now, named 'bluetooth'. This will allow full access to bluez. This will be reserved in the first iteration because there are information leaks and the device can be placed into discovery mode. Other accesses were not investigated but are presumably present.

In the future, bluez will gain trust-store integration (with corresponding system settings updates) so that access to bluez can be safely granted to apps. We might leave 'bluetooth' as reserved and create new policy groups like bluetooth-file-transfer, bluetooth-input, etc.

FYI, I'm working through the policy in a very fine-grained manner to understand it and will post my results here. I can say that the first click example seems to work ok on the sender, but all transfers fails-- either to my laptop (even after enabling bluetooth and visibility and using gnome-file-share-properties to allow receiving files with notifications) or to another phone and using the app from the first click (both are makos). In both cases, there are no apparmor denials for the shareapp.

Ok, I examined all the policy and created a very broad profile called "bluetooth": http://bazaar.launchpad.net/~ubuntu-security/apparmor-easyprof-ubuntu/trunk/view/head:/data/policygroups/ubuntu/1.3/bluetooth

This gives all access to bluez and is therefore reserved. I was able to successfully transfer a file to my laptop from the device using the shareapp from click #1. I was also able to run both the client and the server of click #2 without denials (but the apps couldn't communicate after connecting (unrelated to apparmor)).

In addition, for future reference and so the investigation is not lost, I committed 'bluetooth-net' and 'bluetooth-file-transfer' in the 'pending/' directory: http://bazaar.launchpad.net/~ubuntu-security/apparmor-easyprof-ubuntu/trunk/files/head:/pending/policygroups/

This policy is not read for consumption-- we need trust-store integration in bluez for these to become 'common', but again, wanted to capture the work somewhere in case it is useful in the future.

I'll work on getting these things landed in silos, etc next.

FYI, vivid packages are here: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-015

I'm still turning the crank on xenial and the landings.

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

---------------
apparmor-easyprof-ubuntu (16.10.1) yakkety; urgency=medium

  * add 16.10 policy
  * add bluetooth-net and bluetooth-file-transfer to pending/
  * add reserved ubuntu/bluetooth (LP: #1569582)

 -- Jamie Strandboge <email address hidden> Tue, 10 May 2016 16:21:46 -0500

To test these clicks, we either need new clicks that specify the 'bluetooth' reserved policy or, modify /var/lib/apparmor/clicks/...json to add "bluetooth" to the policy_groups, then rm -f /var/lib/apparmor/profiles/click_..., then do 'sudo aa-clickhook' (this modifies the installed security manifest and regenerates the profile).

FYI, this is ready for QA signoff: https://requests.ci-train.ubuntu.com/#/ticket/1404

apparmor-easyprof-ubuntu (16.04.6) xenial; urgency=medium

  * add reserved ubuntu/bluetooth (LP: #1569582)

 -- Jamie Strandboge <email address hidden> Tue, 10 May 2016 17:02:27 -0500

apparmor-easyprof-ubuntu (1.3.17) vivid; urgency=medium

  * add reserved ubuntu/bluetooth (LP: #1569582)

 -- Jamie Strandboge <email address hidden> Tue, 10 May 2016 15:24:12 -0500

@Michael: Does this mean after OTA-11 you can publich your Bluetooth app to the official Ubuntu Store? :) Or we will still need to use wich is published in the OpenStore?