Hi! In our application confinement specification[1] we define how to confine applications developed with the Ubuntu SDK using AppArmor (aa-easyprof). In short, the approach is to use template-based AppArmor policy (eg, ubuntu-sdk, ubuntu-html5, etc) along with AppArmor policy groups (eg, qmlscene, online-accounts, etc). The idea is that applications developer should not be required to know the ins and outs of Ubuntu and AppArmor, but instead they simply use the SDK and declare various accesses that the app needs. We know have all the low level bits in place such that the fine Ubuntu SDK folks can start integrating this work.
In essence, packaging is updated to include a JSON manifest file and then updated to produce/install the apparmor policy and then load it into the kernel. The JSON security manifest will be a part of the larger click package manifest, but can also stand alone and be used with traditional packaging. Tools for using the security manifest with traditional Debian/Ubuntu packaging are in saucy now, with click package hooks coming online soon. I've created a wiki page[2] to describe the JSON structure, the meaning of the various parts, and how to use aa-easyprof in Click and traditional packaging. Some ideas on integrating this work: * generate a preliminary security manifest based on the type of application that is being created. If Ubuntu Simple/Tabbed Touch UI, use the ubuntu-sdk template with the qmlscene and qmlscene-sqlite policy groups. If a Ubuntu HTML5 Touch UI, use the ubuntu-sdk-html5 template with the qmlscene, qmlscene-webview and networking policy groups * prefill the manifest with entries based on the click packaging manifest[3] * follow the guidelines for using the manifest in traditional packaging[4] * in the short term, app developers could then modify the manifest from the SDK (nice JSON syntax highlighting and checking would be helpful), but eventually, provide some sort of a GUI that the app developer could use to pick and choose different policy groups. Right now, there aren't very many policy groups, but you can enumerate them with aa-easyprof and then expose them to the user as checkboxes. In the long run, it would be cool for the SDK to detect which policy groups are needed based on what the developer is doing with the code. * start fixing paths used by SDK applications to work within our application confinement strategy[5] (against ubuntu-qtcreator-plugins and tagged with 'application-confinement') The security team is available in #ubuntu-hardened, #ubuntu-touch, #ubuntu-devel, on this list and anywhere else you need us. Work is being tracked in the security-s-appisolation-sdk blueprint[6]. Thanks! [1]https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement [2]https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest [3]https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest#Click [4]https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest#Traditional_packaging [5]http://tinyurl.com/mf28tw4 [6]https://blueprints.launchpad.net/ubuntu/+spec/security-s-appisolation-sdk -- Jamie Strandboge http://www.ubuntu.com/
signature.asc
Description: OpenPGP digital signature
-- Ubuntu-devel-discuss mailing list Ubuntu-devel-discuss@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
