Application confinement, manifests and the Ubuntu SDK

[Jamie Strandboge]

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/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20130702/ef7bc6ea/attachment.sig>