Re: Runtime and Security Model for Web Applications

On Wed, Jan 2, 2013 at 3:57 AM, John Lyle <john.lyle@cs.ox.ac.uk> wrote:
> On 28/12/12 20:20, Mounir Lamouri wrote:
>>
>> Hi,
>>
>> On behalf of Mozilla, I would like to propose the following document as
>> a base to work on the 'Execution Model' and the 'Security Model'
>> deliverables for this Working Group's Phase 1:
>>
>> http://mounirlamouri.github.com/sysapps/proposals/RunTime-Security/Overview.html
>>
>>
>
> Hi Mounir, all,
>
> I have some comments & questions about this proposal, mostly for
> clarification.
>
> I think that the document highlights some really good areas for discussion
> and that there is plenty of overlap with our proposal.
>
> * The abstract should probably read "This document specifies the runtime and
> security model of _System Level_ Web Applications".

Depends on what you mean by "system level". The intent is that the
spec defines the behavior both for built-in applications like the
dialer or contacts, as well as third-party apps that can be developed
by anyone and installed through a store or through a webbrowser.

> * Is there a special reason why application manifests need to be redefined,
> considering the presence of Widget packaging standards?  Is it just the need
> to define new elements, or a desire to get away from XML, or both?  Both of
> which are perfectly good reasons, I'm just interested to know the
> motivation.

We felt that using JSON was more natural to web developers than using
XML. It also made the definition easier and it's easier to expose the
manifest to web pages.

There was also quite a few features from the Widget family of specs
that we didn't want in the app runtime and so it felt better to do a
clean cut from widgets, than to try to carve out just the feature set
that we wanted. Doing just parts of widgets will almost certainly lead
to a lot of confusion about what is implemented as well as a lot of
pressure to implement the remaining feature set.

In short, given that mostly what we wanted to lift from widgets was a
simple hierarchical name-value storage, it didn't seem to buy us a
whole lot to grab that from widgets.

> * "required_features" is distinct from "permissions".  What happens when a
> permission is requested for a feature that isn't required?  Or the other way
> around?

Note that the strings for "required_features" and "permissions" are
very different. "permissions" should be thought of as capabilities,
whereas "required_features" is more about specific platform features
such as APIs or CSS properties.

But if the app asks for permission for a feature but doesn't ensure
that the feature exists, then it's likely that part of the app won't
work correctly. Just like if there is no permission involved. I.e. if
an app wants to use a feature but then doesn't list it in
"required_features".

We haven't yet worked out exactly which features to express in
"required_features", so this is definitely an area where input would
be great.

> * Is there a concept of a feature or permission that is optionally required?
> I'm thinking of situations where the device is under a corporate policy, for
> example, and a certain feature or permission can't be granted under any
> circumstance.  Can an application express that this feature is a deal
> breaker, or are all 'required' features actually optional?

Simply don't put the feature in "required_features" and do runtime
testing to check if the feature is available. For example to test if
indexedDB is implemented, do

if ("indexedDB" in window) { ... }

> * The 'version' string is not interpreted, but in the 'updates' section, the
> UA is supposed to compare version numbers.  Can you elaborate on the purpose
> of the version number?

The version number is only intended to be displayed to the user. I'm
not actually convinced that the SHOULD in the "update" section is a
good idea.

> * Where is the origin of the application defined by the app?  It isn't
> listed in the manifest properties, but referenced frequently.  In
> particular, section 3.1 lists the 'origin' as being the origin described in
> the manifest, separately from the installOrigin.

For hosted applications, it's the origin where the application
manifest is located.

For packaged apps, it's "app://" plus the unique identifier generated
when the packaged app is installed.

> * Is it intended that the developer's website be connected, in any way, to
> the origin of the web app or manifest?  Is the developer's website purely
> given for information?

For hosted apps, the developer can, and likely often will want to,
host the application on their website. That way the same URLs can be
used to serve both the website and the app.

Consider for example a twitter app. It makes a lot of sense to use the
same URLs to serve both the twitter website as well as the twitter
app.

> * For packaged apps there are two copies of a manifest: one outside and one
> inside.  Which has precedence?  What happens when they conflict?  You
> mentioned that this is for update / installation purposes - could you
> elaborate?  It seems to me that these shouldn't both be called 'manifest' as
> they serve different purposes and have different contents.

I would personally call the file which is outside of the package
something other than simply a manifest. Maybe an update-manifest. The
contents of the manifest outside of the package is intended to be used
*only* for the install and update of apps. So it'll only contain
enough meta-data that it allows the runtime to display an install
dialog and then download the actual app package. As well as download
future updates.

IIRC that currently means the application name, the developer
information and the metadata about the app package itself, i.e. the
location, the size and the hash. Out of these only the app name and
the developer information is duplicated between the external manifest.
For those we enforce that the data is the same between the two
manifests. If it's not we treat that as a download error.

> Does the
> manifest inside the package contain the 'package' section?  If not, it wont
> contain a copy of the URL of the package, which might be a problem for
> downloading updates.

Note that the install function is given the URL of the
update-manifest. And through that you can get the URL of the latest
version of the app package. So there's no need to get the URL of the
app package from the app package itself.

> How is the application manifest inside the package
> proof that the update is genuine?  Are you assuming that packages are served
> from trusted origins only over TLS/SSL?

It's the responsibility of the store to make sure to use safe
protocols to deliver he update-manifest and the app package.

We've also been using a signing mechanism to sign app packages, though
this isn't yet a generalized mechanism but rather only works for
stores which the app runtime has built-in certificates for. The spec
mentions this briefly, but more detail is definitely needed. The
intent of this signing mechanism is not however to be generic
mechanism to ensure that updates are authentic, but rather a mechanism
to ensure that applications which have access to sensitive APIs are
authentic.

However it would be nice to make this mechanism more generic to allow
it to be used in more situations.

> * Can packaged apps load anything (images, for example) from the network?

The normal web security model applies. The web allows pointing an
<img> to a cross-origin image, but puts limitations on the ability to
read pixel data if the <img> was loaded cross origin.

And if you want to load data using XMLHttpRequest cross-origin, you'll
have to use CORS.

> * You don't seem to have defined 'hosted' applications, except "not a
> packaged application".  Can a system application be a hosted application?
> This is a bit unclear.

Again, depends on your definition of a "system application".

> * Applications are isolated from each other.  In some of our (webinos) use
> cases, apps need to be able to communicate with each other in a limited way
> (e.g., over a message channel).  Is this forbidden in your proposal?  Or can
> one application trigger a System Message to another somehow?

We envision that separate specifications are developed for these
intents. For example our WebActivities proposal allows for limited
cross-application communication. Similar specifications can be
developed to allow more advanced cross-application communication.

> * What is the 'pool of messages' used for when an application has no message
> handler?  Is this in case the application defines a message handler
> subsequently, and then receives all the (old) messages?

Yes, the pool stores old messages until the application signals that
it's ready to receive them using the setMessageHandler function.

For more details about the use-cases and requirements for system messages see

https://groups.google.com/forum/#!topic/mozilla.dev.webapi/o8bkwx0EtmM/discussion

> * Permissions can be granted automatically, denied automatically,
> granted/denied by the user at install time, or granted/denied by the user at
> runtime.  Is there a file or system for saving these decisions and
> specifying defaults?  This (or at least requirements for it) seem like a
> good thing to include in a potential standard.

How the runtime saves security decisions is up to the implementation.

However note that the intent is that there will be *no* security
decisions to be made at install/update time. This is quite intentional
since we want users to be able to always automatically get updated to
the latest version of an app without having to make security
decisions. Otherwise you'll end up in situations where the user will
have to choose between running an old exploitable version of an app,
or a new version which is asking for a permission that the user
doesn't want to grant.

Instead all security decisions are made at runtime.

But UAs are also allowed let users configure policies which
automatically grant/deny certain permissions.

This stuff definitely needs to be defined in more detail in the spec.

> * The "basic Permissions" specified in 8.3 - is this list exhaustive, or are
> these only examples?  Geolocation seems an odd one to include with the
> others - in our experience, Geolocation is bit 'special'.

Note that none of these permissions are granted to applications by
default. This is simply a list of permissions that an application can
request.

Other specs can, and should define more permissions. For example we
expect the Telephony spec to define at least a "telephony" permission,
and maybe a "calllog" permission. So the list is by no means
exhaustive.

> * I think section 8.4.1 is oversimplified.  Is there a threat model or a
> risk analysis available from B2G that we should be referring to?

Yes, section 8.4 in general needs more details. We don't have any
specific threat models, but there's some background available at

https://wiki.mozilla.org/Apps/Security

> * I suggest not using the terms 'trust', 'trusted', 'trusty' or similar in
> specifications because it inspires no end of confusion (see Dieter
> Gollmann's classic essay "Why Trust is Bad For Security").  If such words
> really need to be used, a definition would be helpful.

I agree. We've been using the word "privileged" internally which I
think works better.

> * I'm concerned that relying only on the trustworthiness of the origin of an
> application is too limited a measure.  It removes the opportunity for system
> level applications to be side-loaded (which is a *big* decision to make) as
> well as having some other limitations.  I can't place trust in an author,
> only a distributor.  It also provides no way for application developers to
> have assurance in the integrity of their packaged apps that are distributed
> by third parties.  However, as I'm aware this is the approach taken in
> Firefox extensions, i'd be interested to know whether you have analysed how
> well this has worked in your experiences.

We've not actually implemented putting trust in a developer so far.
The only thing we've implemented is putting trust in a specific
application, and doing so after review. That is the same model as
we're using for Firefox addons and so we don't really have any
experience that I know of of the other model.

> * Section 8.4.4 seems to be a discussion rather than a set of security
> considerations.  I think there's a good case for a more strict set of
> security requirements, expected threats and definition of the relationships
> and reliance between different parties involved.  I would be very happy to
> collaborate on such a section.

Help here would be greatly appreciated.

> * Section 8.4.5 - We have a broadly similar CSP policy in webinos, but we
> haven't trialled it extensively with developers yet.  Do you have any
> experience with this recommendation so far?

I haven't heard any explicit feedback from 3rd party developers yet.
It was surprisingly easy to apply this policy to the built-in apps
that we are shipping with Firefox OS though.

The feedback that I've heard from CSP in general is that forbidding
inline script is a rather big hurdle. But it's unfortunately required
in order to not make script injection possible.

I think the policy isn't a huge deal if the app is built with CSP in
mind from the start. But it can be a lot of work to retrofit an app to
use CSP.

> * Section 8.4.5 - In line with the principle of least privilege, in webinos
> we're specifying that applications must specify their 'connect-src' in the
> manifest, such that applications can only connect using websockets / XHR to
> pre-defined domains. Can Packaged apps in this specification create XHRs to
> any origin?

Yes.

> * Section 8.4.5 - If a packaged app embeds an iframe pointing to another
> origin, what is the expected behaviour?

The same thing as happens on the web. The contents of the <iframe>
will run as normal.

/ Jonas

Received on Thursday, 3 January 2013 02:38:29 UTC