[RFC] Improving hardware access for snaps

[Jamie Strandboge]

On 02/02/2015 04:34 AM, Martin Pitt wrote:
> 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:"?
> 
I'm not sure what you were thinking here, but I'm not sure that matters (see
below where I agree with your point). That said, I'll say a few things so we are
on the same page.

A snap need not specify different 'services:' or 'binaries:' for all the
binaries it ships. This means that if there is a service that starts on boot, it
may call out to any programs in the snap's install dir and inherit the policy of
the service. In this manner, specifying <name>/<service> achieves the goals of
giving these helper binaries access.


>  * 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.
> 
That said, I was thinking that if a snap shipped multiple services and/or cli
binaries, it makes sense for each to individually have access to the hardware,
which is why I presented it in the way I did. When considering the existing
automated review process in the store for _Touch_, some of the security policy
templates are not allowed to by used with some of the policy groups, and I was
thinking this would be the same with hardware access. However, I think this
assumption is wrong since it is the Ubuntu Core user adding hardware access to a
snap, and the user really has no insight as to whether one service in a snap
should have access to a particular device or not, so I agree that the default
behavior should not require specifying the service/cli binary.

>  * 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.
> 
I agree for the default case. I'm thinking that there may still be some utility
for an admin to be able to specify the service if they prefer, but I don't feel
passionately about this.


-- 
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/20150204/a43cc6a4/attachment.pgp>