SDK applications require hardware-specific direct access to graphics devices

SDK applications need a bunch of hardware specific accesses to graphics devices. Eg, the ubuntu-sdk AppArmor template has:

  # FIXME: Nexus7 (grouper)
  /dev/nvmap rw,
  /dev/nvhost-* rw,
  /sys/module/nvhost/parameters/* r,
  /sys/module/fuse/parameters/tegra* r,

  # FIXME: Galaxy Nexus specific (maguro)
  /dev/pvrsrvkm rw,

  # FIXME: Nexus 4 (mako)
  /dev/kgsl-3d0 rw,
  /dev/ion rw,

  # FIXME: Nexus 10 (manta)
  /dev/mali[0-9] rw,
  /dev/ion rw,

  # FIXME: nvidia (we could use the nvidia abstraction, but it needs ipc_lock
  # so lets avoid that for now. Note, ~/.nv/GLCache is used unless
  # __GL_SHADER_DISK_CACHE_PATH is set
  /dev/nvidia[0-9] rw,
  /dev/nvidiactl rw,

This is a maintenance nightmare because the devices don't live under a directory (like we have with /dev/dri/ and /dev/snd) but instead in the toplevel /dev directory (how can we possibly keep track of all the devices?). This also makes porting very difficult because the devices could be anything. Furthermore, the write accesses allow applications to attack these devices directly. The current behavior weakens our application confinement policy as well as making it hard to maintain.

The best solution would be to have the access to the devices happen via an out of process helper (eg Mir) and use shared memory (or similar, like on Android) to provide access. This type of architecture could also allow for writes but not reads, which could be useful for other things like DRM.

In the meantime, we could solve the maintenance and ports issue in a couple of ways:
1. by simply creating all these devices under a specific directory in /dev, such as /dev/graphics, and then our apparmor policy would simply have:
  /dev/graphics/* rw,

2. by creating an apparmor directory, eg /etc/apparmor.d/abstractions/hardware/graphics.d, have the template policy '#include <abstractions/hardware/graphics.d>' then adjusting the udev rules to drop apparmor rules into it, eg, mako might use:
ACTION=="add", KERNEL=="kgsl-3d0", OWNER="system", GROUP="system", MODE="0666", RUN+="/usr/sbin/aa-udev-helper --type=graphics --name=%k --devpath=%p --access=rw"

which could create /etc/apparmor.d/abstractions/hardware/graphics.d/kgsl-3d0 with:
  /dev/kgsl-3d0 rw,

This should work because this device will come up before apparmor policy is loaded. These rules shouldn't change between reboots so there shouldn't be any caching issues. We can create different categories for the devices too-- ie, for the sensor device or gps we have
/etc/apparmor.d/abstractions/hardware/sensors.d/ and /etc/apparmor.d/abstractions/hardware/gps.d/ and policy groups would just include these directories as needed.

3. is a variation on '2' except rather than using udev RUN to generate the policy, the package that ships the udev rule will ship corresponding apparmor policy to drop into /etc/apparmor.d/abstractions/hardware/ somewhere.