MashupOS

From Soma-notes
Revision as of 13:16, 4 October 2012 by Falaca (talk | contribs)

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