SDK applications require hardware-specific direct access to graphics devices

[Jamie Strandboge]

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.

[Ricardo Salveti (rsalveti)]

+1 on option 3.

[Launchpad Janitor (janitor)]

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

---------------
apparmor-easyprof-ubuntu (1.0.35) saucy; urgency=low

  * apparmor-easyprof-ubuntu.install: install data/hardware/*, thus allowing
    porters, OEMs, etc to ship their own policy without having to modify this
    package (LP: #1197133)
  * add data/hardware/graphics.d/* and data/hardware/audio.d/*, namespaced to
    this package. We will move these out to lxc-android-config later
  * tests/test-data.py: adjust to test data/hardware/*
  * accounts: move to reserved status until LP: 1230091 is fixed
  * calendar: remove workaround rule for gio DBus path (LP: #1227295)
  * add usermetrics policy group so apps can update the infographic
  * ubuntu-* templates:
    - allow StartServiceByName on the system bus too. This is needed by the
      new usermetrics policy group and we will presumably have more going
      forward (eg location)
    - account for /org/freedesktop/dbus object path. This seems to be used by
      the python DBus bindings (eg, friends)
    - move hardware specific accesses out of the templates into
      hardware/graphics.d/ in preparation of the move to shipping these in
      lxc-android-config (note, this doesn't change apparmor policy in any
      way)
    - add 'r' to dbus system bus socket (LP: #1208988)
    - add ixr access to thumbnailer helper (LP: #1234543)
    - finetune HUD access
    - don't use ibus abstraction but instead use 'r' access for
      owner @{HOME}/.config/ibus/**
    - don't use freedesktop.org abstraction but instead add read accesses
      for /usr/share/icons and various mime files
    - updates for new gstreamer
      - move in gstreamer accesses from audio policy groupd due to hybris
  * ubuntu-sdk template:
    - remove workaround paths now that ubuntu-ui-toolkit is using
      QCoreApplication::applicationName based on MainView's applicationName
      (LP: #1197056, #1197051, #1224126, LP: #1231863)
  * ubuntu-webapp template:
    - allow read access to /usr/share/unity-webapps/userscripts/**
    - allow rix to gst-plugin-scanner
  * add reserved friends policy group (reserved because it needs integration
    with trust-store to be used by untrusted apps)
  * remove peer from receive DBus rules in the ubuntu-* templates and the
    contacts, history, and location policy groups (LP: #1233895)
  * audio:
    - move gstreamer stuff out to templates since hybris pulls it in for all
      apps
    - include hardware/audio.d for hardware specific accesses
 -- Jamie Strandboge <email address hidden> Mon, 07 Oct 2013 13:18:27 -0500

[Jamie Strandboge (jdstrand)]

I've added the directory for porters to start using, but am not going to move the current policy out to lxc-android-config for saucy. This will happen after 13.10 is released.