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.

• Authors identify four types of content, for which they implement various abstractions
  • Isolated content
  • Access-controlled content
  • Open content
  • Unauthorized content

• 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.
  • <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 that is hosted at and belongs to the integrator ??
  • Opensandbox
    • Ment for any scripted hosted on any domain
  • Service Instance
    • think starting a new process in linux - each alocated it's own resources
    • each service request
  • Commservice request - aka "Ports"
    • Allows separate components to talk to each other threw the parent , but never directly child to child
  • friv
    • the display driver each service instances needs it own display aka friv
  • vop <-- Do we want to talk about
  • sop <-- Do we want to talk about
• 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
    • Do we want to show figure 2 <---- for what they did
    • Do we want to show figure 3 <--- for what they did and how it works