Re: Web app permissions to access WebCrypto related components?

On May 30, 2014 11:51 PM, "Jeffrey Walton" <noloader@gmail.com> wrote:
>
> Thanks Ryan.
>
> On Sat, May 31, 2014 at 2:20 AM, Ryan Sleevi <sleevi@google.com> wrote:
> >
> > On May 30, 2014 11:14 PM, "Jeffrey Walton" <noloader@gmail.com> wrote:
> >>
> >> Are there any plans to require web apps to possess a permission to
> >> access, for example, key storage? Perhaps a read, write and delete
> >> permission?
> >
> > There is no inter-origin key storage. Key storage is handled by
standard web
> > storage APIs, whose privacy and security properties are well understood
and
> > discussed.
> Well, I think there could be more to it.
>
> An (ab)use case I am thinking of: a web based flashlight app wants
> access to a keybag, keychain, keystore, etc. Should an application
> using WebCrypto be allowed to arbitrarily access the keybag, keychain,
> keystore, etc?

Again, to reiterate - there is no keybag, keychain, keystore. None. Zero.
Nada.

There is, at best, IndexedDB, which provides storage for objects that have
declared how they are to be stored, and which can later return these
objects. Which only returns to that web based Flashlight app what that web
based Flashlight app put in.

Why would you ever need a permission or prompt for that? You would not. The
only thing the origin gets is what the origin stored, and that's as
exciting for security as a lump of bricks.

>
> Another (ab)use case I am thinking of: malicious SMS apps can silently
> swallow SMS messages. This is especially bad for those which insert
> themselves first in the chain via android:priority in the manifest,
> get their C&C via text, and then delete the message before anyone sees
> it. Should an application using WebCrypto be allowed to arbitrarily
> and silently delete local material in the keybag, keychain, keystore,
> etc?
>

Again, no keybag, keychain, keystore. Also, no web based SMS apps. If there
is a parallel you intend to draw here, you need to establish how you would
ever get into this situation to begin with - and with the web, you cannot.

> Another (ab)use case I am thinking of: Java applets, permissions and
> code signing. http://threatpost.com/javas-losing-security-legacy. In
> the case of Java, malware authors regularly code sign to break out of
> the sandbox. Applets are so over-permissed that its recommended the
> applet *not* to code sign to ensure they can be contained in the
> sandbox. Is there a WebApp/WebCrypto equivalent to drop permissions?
> Or do apps have to run fully bestowed with full access to the
> platform?
>

Again, suspect this is based on a misunderstanding both of WebCrypto, but
also the general web security model.

There is no 'drop permissions', because the permissions themselves are
inherently things you don't need to drop to begin with, because they are
mitigated as part of being part of the web.

> >> Are there other permissions that might apply in the scope of WebCrypto?
> >>
> >> http://www.w3.org/2012/sysapps/manifest/#permissions-member discusses
> >> a permission member, but I'm having trouble locating a comprehensive
> >> list of available permissions.
> >>
> >
> > Please note, the sysapps security model is different than the webapps
> > security model, as the sysapps charter clearly spells out.
> OK, thanks. I started at Installable WebApps and tried to locate
> something discussing the permissions in the manifest.
>
> Does AOSP/Gogle consider a Hosted App a WebApp, SysApp or something
> different? (
https://developers.google.com/chrome/apps/docs/developers_guide).
>

As the SysApps charter notes, this is conceptually a sys app. Similar to
Firefox extensions. Or B2G Apps. Or, on some levels, similar to WinRT JS
apps.

My use of the term WebApp is a reference to the W3C WebApps WG, that looks
at new APIs to expose to the web - that is, http(s)://foo.example

Web pages don't have code signing, and your UA does not prompt you for a
set of permissions before loading a web page. These two things alone should
highlight how different SysApps and WebApps are, even I'd the share the
same programming and presentation languages.

> > It is possible, in future work, that the WG may decide to expose
> > cryptographic hardware (currently out of chartered scope) or
inter-origin
> > key storage (akin to the Key Discovery API). In these cases, user
agents may
> > implement promoting (for webapps) and permissioning (for sysapps).
> Yes, that's another one that would make a good candidate for a
> permission or capability.
>
> Another that might make a good candidate: crypto algorithms. If an app
> only needs to store a fetch a random value or unique value to track an
> installation, then should the algorithms be partitioned separately?
> Its no different then segregating code and data. In this case, the
> crypto algorithms are essentially code, and the unique values and key
> material are essentially data.
>

No. It does not make sense.

What you just described (unique value to track an installation) is not a
cryptographic property or anything related to this WG.

Applications can, however, use a cryptographically strong random number
generator - such as afforded by the API this WG is producing - and combine
it with existing web storage technologies (localStorage, IndexedDB,
cookies, etc). However, applications can already do that without this API.
It is not exciting.

> > However, all of this is work we are NOT doing right now, so I would not
> > spend too much time on it.
> OK, thanks. I'm trying to determine gaps in the current models.
>
> Jeff
>

Jeff,

While I appreciate the feedback, it does seem you are fairly confused about
this API. While I hope the above is able to provide some clarification, I
would suggest that before you spend too much time worrying about the
security model - and such things like Java sandboxing and code signing - it
might help to focus a bit more on understanding the web security model and
the existing APIs that are part of the platform (eg: IndexedDB).

I can't help but feel like the current comments stem from a place of
misunderstanding, that perhaps the cart was placed before the horse. I only
mention this to make sure that we don't spend too much time discussing the
above responses without first making sure we are on the same page as far as
how the platform works.

This would avoid things like comparison to Java or native applications,
give an understanding of what permissions look like, give an understanding
of what the threats are, what malware conceptually looks like, and all of
these other important concepts. Once this is in place, then its a good
position to evaluate what or how WebCrypto alters this - with the answer
clearly being 'not at all, because it is all possible today, just not as
securely as with WebCrypto'

Cheers,
Ryan