Re: Runtime and Security Model for Web Applications

On 02/01/13 15:35, Janusz Majnert wrote:
> Dear John,
>
> The "Security Requirements for System Applications" document that you 
> submitted is a good read. I think it will be a good base for further 
> work.

Dear Janusz,

Thank you very much for the feedback.


> I have two comments, or rather clarification requests:
>
> 1. Section 6.1 reads:
> " It [the execution environment] shall by default disable applications 
> with no signature or with signatures from entities with unrecoginsed 
> root certificates. However, the exection environment may allow 
> signatures from entities with an unrecognised root certificate if a 
> device owner explicitly permits this."
>
> What is the rationale behind completely disabling apps without 
> signatures and restricting those with untrusted root (this includes 
> self-signed certs)? Isn't this a bit too restrictive?

The wording could be improved here, but the intention was to essentially 
follow the Android model.

Ignoring the difference between author and distributor signatures (we 
intentionally left this vague in this document, but anticipate a 
widget-style approach)  the aim is, by default, to allow only system 
level applications authored or distributed by a known authority, as this 
will eliminate a large amount of potential malware.

If the device owner allows applications that are *not* from a known 
authority (the second clause in this paragraph) then applications should 
still be signed. This allows for subsequent identification of authentic 
updates.  I can't see a particularly good reason to allow unsigned apps, 
although I would be interested in any use cases that made a good case 
for it.I realise that I did not include threats related to application 
updatein the threat model, I'll fix that.

The alternative is to insist on known distributors and rely upon the 
security of the distribution mechanism rather than the integrity and 
authenticity of the individual application package. There are advantages 
and disadvantages to both approaches, but using signed application 
packages allows for several different distribution systems.



> BTW, there's a typo: "exection".

Thanks.  Apologies - there are more typos in this document than I 
realised.  I will issue a new PR to fix them.

>
> 2. Section 10.1 reads:
> "System applications shall not be allowed to execute inline javascript 
> nor shall they be able to execute string-to-JavaScript methods such as 
> eval and function."
>
> What do you mean by "function", is it the Function() constructor? 
> Shouldn't setTimeout and setInterval be included here as well?

Yes, that's a mistake.  I'll fix that.  Thanks!

It might be more sensible for this document to directly reference the 
CSP 'unsafe-eval' section rather than reiterating it.

Best regards,

John

Received on Thursday, 3 January 2013 09:30:58 UTC