Re: Clarification of CSP sandbox and workers
On Thu, Nov 6, 2014 at 5:10 AM, Deian Stefan de...@cs.stanford.edu wrote: 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? This would affect what a worker can fetch, what storage it has access to, and which permissions it has (e.g. can it display a notification). Might be an interesting way to run untrusted code. But if we are going to do something like this Ian would have to define how the sandbox directives affect a worker environment. -- https://annevankesteren.nl/
Re: Clarification of CSP sandbox and workers
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. 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. Ian, WDYT? -mike -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.) On Wed, Nov 12, 2014 at 9:45 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Nov 6, 2014 at 5:10 AM, Deian Stefan de...@cs.stanford.edu wrote: 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? This would affect what a worker can fetch, what storage it has access to, and which permissions it has (e.g. can it display a notification). Might be an interesting way to run untrusted code. But if we are going to do something like this Ian would have to define how the sandbox directives affect a worker environment. -- https://annevankesteren.nl/
Re: Clarification of CSP sandbox and workers
+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
Re: Clarification of CSP sandbox and workers
On Wed, 12 Nov 2014, Mike West wrote: 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. 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. Ian, WDYT? Happy to add features if browsers are going to implement them. Just file a bug describing what the feature is. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Clarification of CSP sandbox and workers
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
