Re: Runtime and Security Model for Web Applications

Regarding signed applications, I believe there is another model
which though only applies to the phase-2 Security Element API.

If you look at the section "How does it work" in:

    http://code.google.com/p/seek-for-android/wiki/AccessControlIntroduction

it seems that the core idea that it is the resource itself that declares
which applications that are allowed to access it.  The applications are
recognized by their digital signature.  I have proposed a similar scheme
to the WebCrypto WG as well.  See page #2 for a quick peek:

    http://webpki.org/papers/PKI/pki-webcrypto.pdf

Anders


On 2013-01-03 11:55, Janusz Majnert wrote:
> 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 11:35:21 UTC