Re: Electrolysis security

On Aug 17, 2009, at 6:45 AM, Benjamin Smedberg wrote:

> On 8/14/09 7:27 PM, Lucas Adamski wrote:
>
> This worries me primarily because we have only the most bare-bones  
> set of
> tests for plugins (I found recently that we seem to have no tests at  
> all for
> the behavior of NPStreams, for example. Do you know of external  
> NPAPI test
> suites that we could use, or tests that plugin vendors would be  
> willing to
> contribute to our codebase?
>

Its in their best interest to ensure that plugins work smoothly within  
electrolysis so I'd image they should be happy to help with testing.   
I think we should engage plugin and other plugin-based browser  
developers to ensure we get a common and workable plugin model anyway  
for future electrolysis phases, as whatever security architecture we  
come up with should be standardized & consistent across browsers.   
Having a different plugin security model for each browser would be a  
nightmare to understand... plugin vs ActiveX is bad enough. :)

>> a) routing all network access through parent process
>
> Being worked-on... we need this without security isolation.
>

I wonder if there's a way for us to eventually verify that there  
aren't direct network calls happening from content processes.  I'm  
concerned about some hacks or special-casing that might have been  
implemented ages ago then forgotten about (such as 307 redirects being  
a separate code path from other redirects).

>> b) how/when can remote tabs access cookies, password manager,
>> certificate information, file system access for file upload/download
>
> Well, they will definitely have to have access to read and write  
> cookies and
> probably passwords for pages loaded in their own domain... and  
> because this
> includes iframes, it's pretty trivial (at least without the  
> newfandled CSP
> stuff) for a process to be granted access to any domain's cookie/ 
> password
> data simply by loading it in an iframe.
>
> File upload/download is easier to control: Chromium presents the  
> file upload
> dialog from the parent process and only grants access to files which  
> have
> been selected in the dialog, which sounds reasonable to me.
>

Yeah, I don't think we'll be able to mitigate all risks, especially  
when it comes to access to session info and credentials, since we  
can't trust any origin information coming from content processes.

Regarding file access, could you elaborate a bit on what you mean by  
"only grants access to files"?   Ideally the file download process  
from the dialog-onwards is a parent-only process that does not involve  
the content process at all (other than simple progress updates).  I  
just want to make sure we're not handing off file paths or handles to  
the content process and/or doing weird filename comparisons on file  
info handed back from the content process, etc.

>> d) preventing impersonation of chrome dialogs by a remote process (to
>> the degree feasible)
>
> I don't think this has much to do with Electrolysis: it's a UI and API
> design issue which can be accomplished independently of multi-process
> issues. From an enginerring perspective I think Electrolysis ought  
> not to
> change our behavior in any way, to avoid unnecessary risk in an  
> already huge
> project.
>

I'm not proposing changing the interaction model but just wondering if  
its possible to prevent content processes from throwing native-looking  
dialogs?  For that matter, how much can we restrict content process  
control over the screen.  Could a content process convincingly fake a  
Vista UAC, for example (efficacy of that mechanism aside :) )?

>> e) cache - who determines origin of documents, who writes to cache?
>
> You mean the network cache? That is managed entirely by the chrome  
> process
> when it's doing network access, and should be basically transparent  
> to the
> content process.
>

Yes, and that sounds good to me.

>> A larger threat model is located at
>> https://wiki.mozilla.org/Security/ProcessIsolation/ThreatModel.   
>> Though
>> it is focused on security improvements from process isolation, it  
>> should
>> still provide useful information for laying the foundation for future
>> phases.
>
> It seems that this is a summary of the threat model for browsers in  
> general.
> You don't expect that a multi-process architecture will address most  
> of
> those threats, correct?
>

It should address it insofar we are conscious of what threats we  
intend to address, and which ones we do not.  So long as we can be  
explicit about which threats we will not be trying to mitigate via  
(later phases of) electrolysis.  Given electrolysis touches virtually  
every part of the browser, I'm not sure its threat model is severable  
from the wider browser security model.
   Lucas.

> --BDS
> _______________________________________________
> dev-tech-dom mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-tech-dom