Re: [Execution and Security Model] Proposal from Samsung Electronics

On 08/01/13 15:33, Jungkee Song wrote:
> Hi all,
>
> Sorry for the belated proposal on Execution and Security Model.
>
> I just made a pull request on the sysapps github. Prospective link is:
> http://sysapps.github.com/sysapps/proposals/Sysapps-Runtime/Overview.html
>
> This is not a counter proposal. We would like to join as co-editors
> for this item and collaborate with other proposed drafts to make it
> forward to a single FPWD.
>
> Your review comments would be appreciated.
>

Hi Jungkee,

I found your proposal to be a good read - I think there's some really 
valuable material in here.  A few comments:

I like the fact that the proposal does not specify a manifest or 
packaging format for now - but does state requirements - that seems to 
allow for all of the existing examples and pass the problem potentially 
over to other specifications.For a stand-alone 'security model' this 
makes a lot of sense.

I broadly agree with the definition of "system application".  I imagine 
it could still be refined, but probably only after the specifications 
have been settled.

I suggest that "the runtime _SHOULD_ support updating of an installed 
system application" might be changed to "_MUST_". Do you have any 
situation in mind where update wouldn't be supported?

With regards to uninstallation - presumably the intention is that a 
runtime must support it, but doesn't necessarily allow anyone to do it?  
I'm thinking of situations where certain system applications are 
pre-installed by the owner of the platform (e.g., a corporation) and 
shouldn't be removed by the end user.

I really like the definition of three browsing contexts.

I'm not so keen on the three-tiered untrusted/trusted/privileged.  I 
think the tiers are sensible, but it would make more sense to describe 
them as (roughly speaking) "unrecognised" / "recognised" /  
"privileged".  It's quite possible that an "untrusted" system 
application could, in fact, be trustworthy and also trusted by the end 
user.  If it has been downloaded and is static on the file system, it's 
integrity could be considered safe anyway, so the fact that it is 
unsigned has very few security implications.  The value of signatures is 
in identifying and categorising applications for the first time, and for 
updates.  E.g., in webinos (and the same is true in Android) we have a 
policy setting for allowing/denying the installation of applications 
without valid certificates.  Once installed, it's unlikely that any 
security policy would differentiate between an "untrusted" and "trusted" 
application for access control reasons, it is much more likely to 
differentiate between "trusted" and "privileged" - e.g., "only 
applications from Samsung can access Telephony" is more likely than 
"only applications from a known authority can access Telephony".

The CSP conflict issue  (issue 4) is one I've been trying to solve in 
webinos, too.  But I'm a little confused - does this mean that a system 
application can be hosted online?  I thought (from other parts of your 
proposal) that apps were always downloaded and then served from the 
local device. Are you saying that - if the application is just one file 
- it can be served over HTTP?

For the sake of simplicity, there's an argument for ignoring 
header-based CSP and requiring it in the manifest. However, in webinos, 
for hosted applications my current proposal (and this really is only 
mine - it hasn't been reviewed yet) is that applications have a 
system-imposed default CSP which can then be modified either by a 
manifest or by HTTP headers.  The modifications are only permitted in 
certain ways - e.g., adding more values to the connect-src, overwriting 
media-src and image-src to be _more_ restrictive.

Issue 5 - relaxing the same origin policy - are there any use cases for 
doing so?  Originally in webinos we were planning to use WARP to specify 
the set of origins that were permitted for a widget.  But CSP seems to 
be more useful.  As such, we decided to stick with the web model (which 
I'm broadly interpreting in this context as "same-origin by default, 
except where permitted by CSP and CORS").  If I understand correctly, 
this is the same in Mounir's proposal.

I agree with the requirement that a runtime obey a security policy, and 
with the principle of defining a reasonable one in this working group 
(although I suspect it'll need to be a 'recommendation' rather than a 
'requirement'.  Your point about differentiating between different 
browsing contexts is good.  I do disagree slightly with "Packaged system 
applications are usually verified extensively by an Application Store" - 
I think this gives app stores more credit than is perhaps deserved.  
There are some app stores out there that do little or no verification.

Best wishes,

John

Received on Wednesday, 9 January 2013 09:59:37 UTC