[RFC] Improving hardware access for snaps

[Martin Pitt]

Hey all,

Jamie Strandboge [2015-01-30 16:18 -0600]:
> $ snappy add-hw foo.bar /dev/ttyS0
> 'foo.bar' is now allowed to access /dev/ttyS0

Would it be possible and prudent to allow hardware access not to a
particular program, but to an entire app? I think this would be better
in several ways:

 * Often you don't want the exposed program to have said capability,
   but a daemon. E. g. you have a daemon which talks to the hardware
   and thus needs the privileges, but there is no reason to expose
   that as "public" binary; you only do that for a possible CLI
   control program (which doesn't need the hw access), or possibly
   you don't even have such a CLI program in the first place. And I
   suppose we don't want to force snaps to have to declare their
   internal daemons as binaries, as these should be "services:"?

 * It doesn't buy you any additional security. foo/bin/baz can always
   call foo/bin/bar to do hw operations on its behalf.

 * Due to the previous point this is inconsistent -- if you give
   add-hw to bar but not baz, then baz can still essentially do the hw
   operation.

 * It entirely avoids the question how to separate the snap name from
   the binary name, and also avoids repetition. A newer version of
   your app might move the hw access to a different internal binary,
   and as these shouldn't be exposed this should be entirely invisible
   to snappy and apparmor profiles.

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/snappy-devel/attachments/20150202/69b59ffd/attachment.pgp>