[RFC] Improving hardware access for snaps

[Loïc Minier]

(Some minor UI remarks that might be helpful to address for some use cases)

First, it's helpful to think about some typical hardware that was brought
up in various discussions:
- serial consoles (/dev/ttyUSB*, /dev/ttyS*, /dev/ttyO* and probably other
names)
- GPIOs (/sys/class/gpio/*)
- webcams (/dev/video*)

Perhaps trickier:
- network (eth0...)
- bluetooth (hci0...)

So perhaps it would make sense to be specific that we're granting access to
files:
snappy add-hw foo.bar file:/dev/ttyS\*

to allow future extensions:
snappy add-hw foo.bar net:eth0

or even more direct:
snappy allow-file foo.bar /dev/xyz
snappy allow-net foo.bar eth0


Bye,


On Fri, Jan 30, 2015 at 11:18 PM, Jamie Strandboge <jamie at canonical.com>
wrote:

>
> = 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/
>
>
> --
> snappy-devel mailing list
> snappy-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/snappy-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20150205/e1d6591f/attachment.html>