[RFC] Snappy frameworks

[Alexander Sack]

On Tue, Mar 24, 2015 at 10:10 PM, Jamie Strandboge <jamie at canonical.com> wrote:
> On 03/19/2015 09:18 PM, Sergio Schvezov wrote:
>> On jueves 19 de marzo de 2015 19h'38:53 ART, Jamie Strandboge wrote:
>>> We've discussed frameworks quite a bit but we've yet to provide a definition,
>>> how they will be used on snappy, how they work with the store and how
>>> they extend security policy. This email attempts to address this (I expect there
>>> to be some fine-tuning but I think it is in good enough shape for wider comment).
>>>
>>> Please see:
>>> http://bazaar.launchpad.net/~jdstrand/snappy/snappy.frameworks-definition/view/head:/docs/frameworks.md
>>>
>>
>> I created an MP with syntax and typo corrections:
>> https://code.launchpad.net/~sergiusens/snappy/snappy.frameworks-definition/+merge/253625
>>
> Thanks! Merged
>
>>
>> wrt some parts of the text:
>> Can frameworks be forked? If yes, the definition of pkgname and the associated
>> policy becomes tricky. The top level discussion makes me assume it is a yes
>>
>> I'm thinking foo.sergiusens, the dbus path for that would still be `/foo/meh`,
>> right? It would be good to reinforce forks in the document (forks are .developer
>> packages in this context).
>>
>> When the policy lives outside of the package, I suppose this would imply that
>> all forks inherit the same policy.
>>
> I wasn't thinking we would allow forks of this nature in the store, but
> developers would be able to sideload a modified framework if they want.
>
> Consider this characteristic of frameworks which informs much of the definition
> of frameworks:
>
>  "Unlike apps, frameworks have special permissions which allow them elevated
>   access to the system"
>
> Frameworks are special. Frameworks are trusted. Frameworks need to be designed
> with security in mind since they increase the attack surface for untrusted apps.
> As such, we shouldn't allow forks of a framework in the store (people may always
> sideload); the framework should just be updated as needed. We will of course
> always support a differently named framework so if people really want to fork,
> they can grab the framework, rename it, rename the file or two in the policy
> directory, rename binaries, etc and when ready to upload to the store, work with
> the store owner (eg, Canonical for the Ubuntu store). I think it is also
> important to remember that there will be relatively few frameworks relative to apps.

Yes you are right. We surely shouldn't allow forks of other parties
then the one we designed the policy for. So making it a clear 1:1
mapping is way to go.

>
> On top of all of that, allowing forks of this nature would add a lot of
> complexity with little benefit due to how frameworks will be managed by store
> processes. Sharing policy is a hard and assuming we could share policy in a
> clean way, we would then have to have rules that worked across all of them which
> would result in a 'lowest common denominator' policy that might not provide the
> protection we want.
>
> One thing that came to mind when drafting this is that there is an interesting
> inconsistency between these characteristics:
> * Frameworks exist primarily to provide mediation of shared resources
> * Frameworks can be installed on the same system without conflicts
>
> The current RFC handles this ok on the filesystem fine. However, we have not
> defined runtime conflicts: what happens if there are two different competing
> frameworks for say, handling a serial device. Framework foo gives app bar access
> to /dev/ttyS0 and framework baz gives app norf access to /dev/ttyS0-- we have a
> runtime conflict.
>
> This is interesting to think about, but I don't think it should block our
> current definition. Since the store owner works with the framework authors, the
> store owner can either choose to only allow one framework per shared resource or
> allow competing frameworks. If the store allows competing frameworks, and since
> this might provide a runtime conflict, we perhaps want to support the concept of
> 'conflicts' at the store level (ie, a store admin can say two frameworks
> conflict, and 'snappy install' knows what to do with that information-- ie,
> don't encode it in the package.yaml or anything).
>
> (IMHO it seems reasonable to have competing frameworks so long as they each
> "provide a significant benefit for many users".)
>
>> With regards to binaries, *top* level binaries and clashing, how is that dealt
>> with while having the coinstall requirement?
>>
> I was thinking this would be coordinated as part of the onboarding process and
> enforced by the review tools.
>
> I've updated the doc based on the above (with a few other minor changes):
> http://bazaar.launchpad.net/~jdstrand/snappy/snappy.frameworks-definition/revision/241
>
> --
> 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
>