Re: Runtime and Security Model for Web Applications

On 2013-01-03 10:30, John Lyle wrote:
> 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.
OK. That makes sense.


> 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.
 From a security/authenticity standpoint, I don't think there is much 
difference between applications signed using an untrusted chain and 
those not signed at all.


> 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.
As for relying on a known distributor list, I think that this is 
actually not an alternative, but rather a necessary condition for 
knowing which applications are to be trusted and which not.

In other words, to know which applications are not from a known 
authority, you already need some sort of list of those authorities that 
you know.

As for relying on the security of the distribution mechanism, you wrote 
earlier that the aim was to allow for Android style signing. Correct me 
if I'm wrong, but I think Android relies heavily on their app store 
solution.

>> 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.
Yes, that's a good idea.


BR/Janusz

Received on Thursday, 3 January 2013 10:55:56 UTC