[RFC] Improving hardware access for snaps

[Jamie Strandboge]

= Introduction =
Right now it is too difficult for snaps to access specific hardware, we've known
that and it is time to improve the situation.

First we want to improve things for people immediately but without sacrificing
on any of our goals[1]. We'll do this by adjusting snappy to give the snappy
core user (ie, the one running the 'snappy' command) the ability to add specific
device access to specific snaps. In essence you install a snap, you run a
command to give the snap access to a particular device, and you’re done. This
simple feature should unblock developers and snappy users immediately. Once this
is done, we can refine the experience to make it even snappier.


= UX =
Relevant packaging yaml:
  name: foo
  version: 0.1
  ...
  services:
    - name: bar
      start: bin/bar
    - name: baz
      start: bin/baz


== adding access ==
$ snappy install foo
...

$ snappy add-hw foo.bar /dev/ttyS0
'foo.bar' is now allowed to access /dev/ttyS0


$ snappy add-hw foo.bar /dev/ttyS1
'foo.bar' is now allowed to access /dev/ttyS1


$ snappy add-hw foo.baz /dev/qux
'foo.baz' from 'foo' is now allowed to access /dev/qux



== listing access ==
(used 'info-hw' instead of 'ls-hw/list-hw' to be consistent with 'snappy info'
command).

$ snappy info-hw
foo:
  bar: /dev/ttyS0, /dev/ttyS1
  baz: /dev/qux
norf:
  quux: ...


$ snappy info-hw foo
foo:
  bar: /dev/ttyS0, /dev/ttyS1
  baz: /dev/qux


$ snappy info-hw foo.bar
foo:
  bar: /dev/ttyS0, /dev/ttyS1



== removing access ==

$ snappy remove-hw foo.bar /dev/ttyS0
'foo.bar' is no longer allowed to access /dev/ttyS0


$ snappy info-hw foo
foo:
  bar: /dev/ttyS1
  baz: /dev/qux



= Implementation =
For the current python implementation, modifying the system for this is not
difficult. Under the hood, when adding a device, snappy would add a 'write_path'
to merge with the installed security json for the snap, then send this to
apparmor-easyprof to update. In the example above after adding the two hardware
devices the final security policy for foo_bar_0.1 that is sent to
apparmor-easyprof is:

  $ cat foo_bar_0.1.json:
  {
    ...,
    "write_path": [
      "/some/preexisting/access",      <== preexisting write_path entry
      "/dev/ttyS0",                    <== added by 'snappy add-hw'
      "/dev/ttyS1"                     <== added by 'snappy add-hw'
    ]
  }

click-apparmor already has the concept of 'overrides' that does something very
similar, so with not a lot of effort we can implement this for hardware.


[1]https://penguindroppings.wordpress.com/2015/01/30/snappy-app-trust-model/

-- 
Jamie Strandboge                 http://www.ubuntu.com/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20150130/71e7dc74/attachment-0001.pgp>