MashupOS

Protection and communication abstractions for web browsers in MashupOS

This paper appears in SOSP '07 Proceedings of twenty-first ACM SIGOPS symposium on Operating systems principles, Pages 1-16. The audience is primarily OS researchers, as opposed to web/security researchers.

• Motivation for the work
  • Authors refer to browsers as "multi-principal operating environments" where mutually distrusting web sites, as principals, interact in a single page on the client side, sharing the underlying browser resources. This is compared to PC operating environments where mutually distrusting users share host resources.
  • However, the authors argue that today's browsers do not employ OS abstractions, and instead provide limited all-or-nothing trust models, and are therefore only suitable for a single-principal system. They aim to fix this with MashupOS.

• Principles of MashupOS
  • Match all common trust levels
  • Strike a balance between ease-of-use and security
  • Easy adoption and no unintended behaviours (i.e. provide fallback mechanisms for legacy browsers)

• Principals and Resources
  • In OS, the principal is a user or group. In the Web, the principal is the owner of some Web content.
  • Resources:
    • Memory: heap of script objects
    • Persistent state: Cookies
    • Display: HTML DOM
    • Network communications: Ability to send and receive messages outside application.

• Existing trust relationship between content providers and integrators: All-or-nothing. Authors identify four types of content, for which they implement various abstractions
  • Isolated content: Completely isolated from other sites.
  • Access-controlled content: Content that is isolated but allows message-passing across domains to give mediated access.
  • Open content
  • Unauthorized content: Content which the integrator an directly access, but does not trust to access the integrator's resources.

• Paper puts heavy emphasis on Sandboxing and isolation

• What they implemented:
  • <ServiceInstance> abstraction for isolation, fault containment, and as the unit of resource allocation and CommRequest for cross-domain communications.
    • Controlled communication between service instances is allowed through the CommRequest abstraction - can be thought of as "ports". Allows separate components to talk to each other through the parent , but never directly child to child.
    • Comparable to starting a new process in Linux - each is allocated its own resources
    • Friv: combines properties of a
      and <iframe>. Acts as the display which each service instance connects to.
  • <Sandbox> and <OpenSandbox> abstractions to enable the provision of unauthorized content without overtrusting it. This is also said to help in combating XSS attacks.
    • <Sandbox>: Private unauthrozed content that is hosted at and belongs to the integrator.
    • <Opensandbox>: May be hosted by any domain.

• Questions
  • Is the new Cross-Origin Resource Sharing comparable to what the authors were referring to as "Verified Origin Policy" (VOP)? Does this solve all the problems with Same Origin Policy (SOP)?
  • Seamless iframes - how similar are they to frivs?

• What was implemented
  • Proxy server and MME filter

• What the testing was
  • Running speed tests not security test , Anil said WHY ? mabey because OS conference cares about speed
  • Open sandbox was not implemented
  • only one service instance per friv

• Conclusions
  • Mostly a theoretical paper
    • But interesting

• Notes
  • Table 1 does a good job at relating the various content types/trust levels with the associated abstractions
  • Figure 2 <---- for what they did
  • Figure 3 <--- for what they did and how it works