Re: Security use cases for packaging

2015-01-29 Thread Deian Stefan


Brad Hill hillb...@gmail.com writes:

 Paging (future Dr.) Deian Stefan to the ER...

 Any thoughts on using COWL for this kind of thing, with a pinned crypto key
 as a confinement label to be combined with the regular Origin label?


Thanks for paging me! I've thought about something like this---providing
some form of code integrity---in the context of COWL as well.

The idea was to grant a worker the privilege corresponding to the (hash
of the) source, in addition to its origin. This would allow a server to
verify if the code it is communicating with is trustworthy.
(COWL labels are not limited to origins.)

I really like Yan's use case. And I think it fits in pretty naturally
with COWL: the app, if verification succeeds, can be granted the
privilege corresponding to the (hash of the) crypto key:
Privilege(https://cryptomail.yahoo.com).and(app-key:...).
Other code from the same origin would only have 
Privilege(https://cryptomail.yahoo.com).

I think this may partly address Chris and Dev's concerns.  But deciding
when not to run the app code is still a question. Though I think the
github issue already brings this up.

Deian



Re: Clarification of CSP sandbox and workers

2014-11-12 Thread Deian Stefan

+1

Mike West mk...@google.com writes:

 The CSP spec should just delegate to HTML here. If/when HTML defines
 sandboxing with regard to Workers, CSP will just start using those hooks.

Reasonable, the issue also appears outside CSP: if I create a worker in
a sandboxed iframe, what should its origin be? (Or should I not be able
to create a worker in this case?)
 
 I'd agree, for example, that it does appear that sandboxing a worker into a
 unique origin could be interesting. It's not clear to me whether any of the
 other flags would be useful, though.

Right, none of the other flags really make sense. (Though some of the
flags similarly don't make sense when the sandbox directive is applied
to a top-level page.) I do think it's reasonable to wait on the more
general sandboxed worker idea, since some of the proposals in WebAppSec
are thinking about this already.

Thanks,
Deian



Clarification of CSP sandbox and workers

2014-11-11 Thread Deian Stefan

Hey guys,

I am implementing CSP for Workers in Firefox, but like to get a
clarification on workers and the sandbox flag. Currently, a Worker can
inherit or be accompanied by a CSP header. As written, the implications
of the sandbox directive on the Worker context is not clear.

[Following up on https://github.com/w3c/webappsec/issues/69]

Arguably most of the sandbox flags don't make sense for Workers, but the
empty directive (i.e., just sandbox) and sandbox allow-same-origin can
have reasonable semantics.  So, if a Worker inherits the CSP from the
owner document (or parent worker in later specs) or is accompanied by a
CSP header which has the 'sandbox' directive, should the worker script's
origin be set to a unique origin?  Or should we just ignore (and
appropriately warn about) the sandbox flag for Workers and address the
need for sandboxed Workers separately?

Thanks,
Deian


signature.asc
Description: PGP signature