Soma-notes - User contributions [en]

OSWebSec: Exokernels

2012-10-17T18:20:19Z

Falaca: /* Formal proof */

==Exokernels==

[[File:ExterminateHWAbstractions.jpg|thumb|Key idea of Engler et al. in ''Exokernel: an operating system architecture for application-level resource managementp'']]

===Portability===
Portability is a major concern with exokernels: In addition to the work required to port the exokernel to different hardware, you also have to port all programs to it since the exokernel provides a different API depending on what hardware it is running on.

The goal of exokernels was to make the system minimal, but at the end of the day you end up adding onto it and providing things like POSIX semantics anyway, and therefore introducing vulnerabilities into your system.

Extensibility is mentioned as a key advantage of exokernels, but modern OSs are quite extensible anyway: You can write kernel modules/device drivers, file systems, etc.

===Exokernels for what?===
The authors mention that many of the hardware abstractions offered by the kernel end up slowing down some specialized applications. But for a monolithic kernel this is no problem: You can just add APIs for specialized tasks to reduce overhead. So who exactly will go through all the pain of using an exokernel, when they can just take an open source OS like Linux and modify it to suit their needs?

===Formal proof===
The authors made some big compromises in order to make a formal proof for their exokernel possible:
* They restricted themselves to a subset of the C language (e.g., no function pointers)
* Gimped concurrency
* Interrupt handling
* Memory allocation (none)

They designed their kernel for uniprocessor systems. How do you verify a multi-threaded kernel? Even without verification, modern kernels took '''a lot''' of work to reach a state where they work correctly.

==Microkernels==
Microkernel subsystems depend on each other to get things done. There are too many tightly coupled services passing around too much data. Compromising one component can allow you to compromise others. ''Where's the win?''

All optimizations that are done to improve microkernels can also be done to monolithic kernels. In class we discussed [http://en.wikipedia.org/wiki/OpenBinder, binder], an IPC system originally designed for microkernels, which has now been implemented for Linux and is used in Android.

==Microkernels vs. Exokernels==
Exokernels appear as hardware to the applications running on it, whereas microkernels provide abstractions.

Some barriers (e.g., user/kernel space) are natural, others aren't. If you try to create barriers where it doesn't make sense to do so, you simply end up breaking too many holes through them make things work correctly. From a security perspective, this brings you back to the same situation you started with because of all the holes that you've created.

OSWebSec: Exokernels

2012-10-17T18:19:03Z

Falaca: /* Portability */

==Exokernels==

[[File:ExterminateHWAbstractions.jpg|thumb|Key idea of Engler et al. in ''Exokernel: an operating system architecture for application-level resource managementp'']]

===Portability===
Portability is a major concern with exokernels: In addition to the work required to port the exokernel to different hardware, you also have to port all programs to it since the exokernel provides a different API depending on what hardware it is running on.

The goal of exokernels was to make the system minimal, but at the end of the day you end up adding onto it and providing things like POSIX semantics anyway, and therefore introducing vulnerabilities into your system.

Extensibility is mentioned as a key advantage of exokernels, but modern OSs are quite extensible anyway: You can write kernel modules/device drivers, file systems, etc.

===Exokernels for what?===
The authors mention that many of the hardware abstractions offered by the kernel end up slowing down some specialized applications. But for a monolithic kernel this is no problem: You can just add APIs for specialized tasks to reduce overhead. So who exactly will go through all the pain of using an exokernel, when they can just take an open source OS like Linux and modify it to suit their needs?

===Formal proof===
The authors made some big compromises in order to make a formal proof for their exokernel possible:
* They restricted themselves to a subset of the C language
* Gimped concurrency
* Interrupt handling
* Memory allocation (none)

They designed their kernel for uniprocessor systems. How do you verify a multi-threaded kernel? Even without verification, modern kernels took '''a lot''' of work to reach a state where they work correctly.

==Microkernels==
Microkernel subsystems depend on each other to get things done. There are too many tightly coupled services passing around too much data. Compromising one component can allow you to compromise others. ''Where's the win?''

All optimizations that are done to improve microkernels can also be done to monolithic kernels. In class we discussed [http://en.wikipedia.org/wiki/OpenBinder, binder], an IPC system originally designed for microkernels, which has now been implemented for Linux and is used in Android.

==Microkernels vs. Exokernels==
Exokernels appear as hardware to the applications running on it, whereas microkernels provide abstractions.

Some barriers (e.g., user/kernel space) are natural, others aren't. If you try to create barriers where it doesn't make sense to do so, you simply end up breaking too many holes through them make things work correctly. From a security perspective, this brings you back to the same situation you started with because of all the holes that you've created.

OSWebSec: Exokernels

2012-10-17T18:17:43Z

Falaca:

==Exokernels==

[[File:ExterminateHWAbstractions.jpg|thumb|Key idea of Engler et al. in ''Exokernel: an operating system architecture for application-level resource managementp'']]

===Portability===
Portability is a major concern with exokernels: In addition to the work required to port the exokernel to different hardware, you also have to port all programs to it since the exokernel provides a different API depending on what hardware it is running on.

The goal of exokernels was to make the system minimal, but at the end of the day you end up adding onto it and providing things like POSIX semantics anyway.

Extensibility is mentioned as a key advantage of exokernels, but modern OSs are quite extensible anyway: You can write kernel modules/device drivers, file systems, etc.

===Exokernels for what?===
The authors mention that many of the hardware abstractions offered by the kernel end up slowing down some specialized applications. But for a monolithic kernel this is no problem: You can just add APIs for specialized tasks to reduce overhead. So who exactly will go through all the pain of using an exokernel, when they can just take an open source OS like Linux and modify it to suit their needs?

===Formal proof===
The authors made some big compromises in order to make a formal proof for their exokernel possible:
* They restricted themselves to a subset of the C language
* Gimped concurrency
* Interrupt handling
* Memory allocation (none)

They designed their kernel for uniprocessor systems. How do you verify a multi-threaded kernel? Even without verification, modern kernels took '''a lot''' of work to reach a state where they work correctly.

==Microkernels==
Microkernel subsystems depend on each other to get things done. There are too many tightly coupled services passing around too much data. Compromising one component can allow you to compromise others. ''Where's the win?''

All optimizations that are done to improve microkernels can also be done to monolithic kernels. In class we discussed [http://en.wikipedia.org/wiki/OpenBinder, binder], an IPC system originally designed for microkernels, which has now been implemented for Linux and is used in Android.

==Microkernels vs. Exokernels==
Exokernels appear as hardware to the applications running on it, whereas microkernels provide abstractions.

Some barriers (e.g., user/kernel space) are natural, others aren't. If you try to create barriers where it doesn't make sense to do so, you simply end up breaking too many holes through them make things work correctly. From a security perspective, this brings you back to the same situation you started with because of all the holes that you've created.

File talk:ExterminateHWAbstractions.jpg

2012-10-11T02:32:20Z

Falaca: Blanked the page

OSWebSec: Exokernels

2012-10-11T01:48:57Z

Falaca: Created page with "File:ExterminateHWAbstractions.jpg"

[[File:ExterminateHWAbstractions.jpg]]

File talk:ExterminateHWAbstractions.jpg

2012-10-11T01:48:08Z

Falaca: Created page with "File:ExterminateHWAbstractions.jpg"

[[File:ExterminateHWAbstractions.jpg]]

File:ExterminateHWAbstractions.jpg

2012-10-11T01:47:03Z

Falaca: Key idea presented in papers by Engler et al.

Key idea presented in papers by Engler et al.

MashupOS

2012-10-04T13:52:59Z

Falaca:

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 <div> 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

MashupOS

2012-10-04T13:41:49Z

Falaca:

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 <div> 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.

** 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

MashupOS

2012-10-04T13:16:23Z

Falaca:

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