The computing industry has been rapidly transitioning to a
software-as-a-service paradigm, embracing service portability across
devices, enabling rapid cycles of innovations from software vendors,
and incurring minimal software management from users. Services differ
from traditional applications in three fundamental ways: 1) a
service's master copy is
remote (in the cloud); 2) services are untrusted to
access one another and to user-private resources (like sensors or
data); 3) services often embed other services to enable rich
service compositions. These differences have signficant implications
on the design of client operating systems in terms of protection,
resource sharing and access control. In the ServiceOS project, we
rethink the client platform design in these dimensions. Our ServiceOS
vision is detailed in this HotSec
position paper.
Our first subproject is MashupOS in which we observed that web sites are OS principals on web browsers and web applications demand browsers to offer OS abstractions for protection and cross-principal communications. The full paper on MashupOS is published at SOSP 2007 and a position paper was published at HotSec 2007.
Although web browsers function as operating systems, they have
never been designed and implemented as an OS. We then built the
Gazelle web browser which is the first browser that takes a
multi-principal OS-based design and construction, where web sites are
OS principals and unit of protection and all OS logic (such as the
same-origin policy and resource access) is exclusively done in
a browser kernel in a separate protection domain from that of browser
renderers. We detailed this work in
a paper
published at Usenix Security 2009. The special characteristics of
services also required rethinking of resource scheduling, which is
detailed in
this technical
report.
With any new browser design, one often worries about its compatibility cost. Gazelle enforces an unified same-origin policy (SOP), applying SOP to all resources (DOM or cookie or remote access) and to all content types (HTML, Flash, Java programs or images). In contrast, existing web browsers' access control policies have evolved piecemeal in an ad-hoc fashion with the introduction of new browser features, resulting in numerous incoherencies. Although we can make Gazelle compatible with existing browsers through the use of cross-principal communications, we want to enable browser vendors to make tradeoffs between security and compatibility and have a data-driven browser design. To this end, we built a WebAnalyzer tool to crawl the web, emulate page browsing, and measure the compatibility cost of ridding unsafe browser features. We detailed this work in a paper published at Oakland 2010.
Widespread growth of open wireless hotspots has made it easy to carry out man-in-the-middle attacks and impersonate web sites. Although HTTPS can be used to prevent such attacks, its universal adoption is hindered by its performance cost and its inability to leverage caching at intermediate servers (such as CDN servers and caching proxies) while maintaining end-to-end security.
To complement HTTPS, we revive an old idea from SHTTP, a protocol that offers end-to-end web integrity without confidentiality. We name the protocol HTTPi and give it an efficient design that is easy to deploy for today’s web. In particular, we tackle several previously-unidentified challenges, such as supporting progressive page loading on the client’s browser, handling mixed content, and defining access control policies among HTTP, HTTPi, and HTTPS content from the same domain. Our prototyping and evaluation experience show that HTTPi incurs negligible performance overhead over HTTP, can leverage existing web infrastructure such as CDNs or caching proxies without any modifications to them, and can make many of the mixed-content problems in existing HTTPS web sites easily go away. Based on this experience, we advocate browser and web server vendors to adopt HTTPi.
An initial writeup on the work
is here.
We further generalize Gazelle's design to that of a client
OS. With cloud centric computing, remote content has become the first
class citizen for all applications including not only web browsers,
but also document-processing applications, such as word processors,
photo viewers, and media players. The implication here is that the
client OS needs to adopt the same-origin policy kind of mentality from
that of browsers and offer protection for remote content of different
owners. We are pursuing an OS design that offers this protection while
being compatible with existing web security and at the same time
allowing easy adaptation of existing native applications.
Modern client platforms, such as iOS, Android, web browsers, and ServiceOS, run each application in an isolated environment with limited privileges. A pressing open problem in such systems is how to allow users to grant applications access to user-owned resources, e.g., to privacy- and cost-sensitive devices like the camera or to the user's data that resides with various applications. A key challenge is to enable such access in a way that is non-disruptive to users while still maintaining least-privilege restrictions on applications. We propose user-driven access control, whereby permission-granting is built into existing user actions, rather than added as an afterthought via manifests or prompts. To this end, we introduce two OS-level techniques, access control gadgets and kernel-recognized gestures, for controlling access to user-owned resources. Our initial writeup of the work is detailed here.
The communication abstraction proposed in MashupOS influenced the design of the "postMessage" cross-domain communication API in HTML5, which is now implemented in all major browsers.
The sandbox abstraction proposed in MashupOS significantly influenced "iframe sandbox" design in HTML5, which starts to see browser adoption.
Learning from the MashupOS experience, we developed an Ad isolation
system using cross-domain iframes for Microsoft Ad Center. Our system
is now adopted. Microsoft has also proposed the corresponding API,
called Microsoft
Display Ad SmartServe API, for standardization in the Ad industry.