國外操作系統(tǒng)相關(guān)論文trustandprotectionintheillinoisbrowseroperatingsystem

1、Trust and Protection in the Illinois Browser Operating SystemShuo Tang, Haohui Mai, Samuel T. King University of Illinois at Urbana-ChampaignAbstractCurrent web browsers are complex, have enormous trusted computing bases

2、, and provide attackers with easy access to modern computer systems. In this paper we in- troduce the Illinois Browser Operating System (IBOS), a new operating system and a new browser that re- duces the trusted computin

3、g base for web browsers. In our architecture we expose browser-level abstractions at the lowest software layer, enabling us to remove al- most all traditional OS components and services from our trusted computing base by

4、 mapping browser abstrac- tions to hardware abstractions directly. We show that this architecture is flexible enough to enable new browser se- curity policies, can still support traditional applications, and adds little

5、overhead to the overall browsing experi- ence.1 IntroductionWeb-based applications (web apps), browsers, and op- erating systems have become popular targets for attack- ers of computer systems. Vulnerabilities in web app

6、s are widespread and increasing. For example, cross-site scripting (XSS), which is effectively a form of script in- jection into a web app, recently overtook the ubiquitous buffer overflow as the most common security vul

7、nerabil- ity [50]. Vulnerabilities in web browsers are less com- mon than web app vulnerabilities, but still occur often. For example, in 2009 Internet Explorer, Chrome, Safari, and Firefox had 349 new security vulnerabi

8、lities [4], and attackers exploit browsers commonly [53, 37, 42, 41, 4]. Vulnerabilities in libraries, system services, and oper- ating systems are less common than vulnerabilities in browsers, but are still problematic

9、for modern systems. For example, glibc, GTK+, X, and Linux had 114 new security vulnerabilities in 2009 [1], and in 2009 the most commonly attacked vulnerability was a remote code ex- ecution bug in the Windows kernel [4

10、].However, not all attacks on web apps, browsers, and operating systems are equally virulent. At the top of the computer stack, attacks on web apps, such as XSS, oper- ate within current browser security policies that co

11、ntain the damage to the vulnerable web app. Moving down the computer stack, attacks on browsers can cause more damage because a successful attack gives the attacker ac- cess to browser data for all web apps and access to

12、 other resources on the system. At the lowest layers of the computer stack, attacks on libraries, shared system ser- vices, and operating systems are the most serious attacks because attackers can access arbitrary states

13、 and events, giving them complete control of the system.Overall, these trends indicate that vulnerabilities higher in the computer stack are more common, but vul- nerabilities lower in the computer stack provide attack-

14、ers with more control and are more damaging. In this paper we focus on preventing and containing attacks on browsers, libraries, system services, and operating sys- tems – the lower layers of the computer stack.Current r

15、esearch efforts into more secure web browsers help improve the security of browsers, but remain susceptible to attacks on lower layers of the computer stack. The OP web browser [26], Gazelle [52], Chrome [11], and Chrome

16、OS [25] propose new browser architectures for separating the functionality of the browser from security mechanisms and policies. However, these more secure web browsers are all built on top of commodity operating systems

17、 and include complex user-mode libraries and shared system services within their trusted computing base (TCB). Even kernel designs with strong isolation between OS components (e.g., microkernels [24, 27, 28] and informat

18、ion-flow ker- nels [18, 57, 33]) still have OS services that are shared by all applications, which attackers can compromise and still cause damage. Here are a few ways that an attacker can still cause damage to more secu

19、re web browsers built on top of traditional OSes:1Hardware Browser abstractions IBOS Kernel L4 Reference Monitor UI Storage … Web Page Instance Web Page Instance Web Page Instance maps.com bing.com uiuc.edu UNIX L

20、ayer Traditional Applications localhost Mouse/KBD Driver NIC Driver Net. Manager NIC Mouse/KBD Video … Net. Processes Figure 1: Overall IBOS architecture. Our system con- tains user-mode drivers, browsers API manage

21、rs, web page instances, and traditional processes. To manage the interactions between these components, we use a refer- ence monitor that runs within our IBOS kernel. Shaded regions make up the TCB.3. Maintain compatibil

22、ity with current browser secu- rity policies. Our primary goal is to improve the enforcement of current browser policies without changing current web-based applications.4. Expose enough browser states and events to enabl

23、e new browser security policies. In addition to en- forcing current browser policies, we would like our architecture to adapt easily to future browser poli- cies.5. Avoid rule-based OS sandboxing for browser com- ponents

24、. Fundamentally, rule-based OS sandbox- ing is about restricting unused or overly permis- sive interfaces exposed by today’s operating sys- tems. However, sandboxing systems can be com- plex (the Ubuntu 10.04 SELinux ref

25、erence policy uses over 104K lines of policy code) and difficult to implement correctly [23, 51]. If our architecture re- quires OS sandboxing for browser components then we should rethink the architecture.2.2 Overall ar

26、chitectureFigure 1 shows the overall IBOS architecture. The IBOS architecture uses a basic microkernel approach with a thin kernel for managing hardware and facilitating mes- sage passing between processes. The system in

27、cludes user-mode device drivers for interacting directly with hardware devices, such as network interface cards (NIC), and browser API managers for accessing the drivers andimplementing browser abstractions. The key brow

28、ser abstractions that the browser API managers implement are HTTP requests, cookies and local storage for stor- ing persistent data, and tabs for displaying user-interface (UI) content. Web apps use these abstractions di

29、rectly to implement browser functionality, and traditional ap- plications (traditional apps) use a UNIX layer to access UNIX-like abstractions on top of these browser abstrac- tions.2.2.1 The IBOS kernelOur IBOS kernel i

30、s the software TCB for the browser and includes resource management functionality and a refer- ence monitor for security enforcement. The IBOS kernel also handles many traditional OS tasks such as manag- ing global resou

31、rces, creating new processes, and man- aging memory for applications. To facilitate message passing, the IBOS kernel includes the L4Ka::Pistachio [8] message passing implementation and MMU manage- ment functions. All mes

32、sages pass through our reference monitor and are subjected to our overall system security policy. Section 4 describes the policies that the IBOS kernel enforces and the mechanisms it uses to implement these policies.2.2.

33、2 Network, storage, and UI managersThe IBOS network subsystem handles HTTP requests and socket calls for applications. To handle HTTP re- quests, network processes check a local cache to see if the request can be service

34、d via the cache, fetch any cook- ies needed for the request, format the HTTP data into a TCP stream, and transform that TCP stream into a series of Ethernet frames that are sent to the NIC driver. Socket network processe

35、s export a basic socket API and simply transform TCP streams to Ethernet frames for transmis- sion across the network. Only traditional apps can access our socket network processes. The IBOS kernel manages global states,

36、 like port allocation. The IBOS storage manager maintains persistent stor- age for key-value data pairs. The browser uses the stor- age manager to store HTTP cookies and HTML5 local storage objects, and the basic object

37、store includes op- tional parameters, such as Path and Max-Age, to ex- pose cookie properties to the reference monitor. The storage manager uses several different namespaces to isolate objects from each other. Web apps a

38、nd net- work processes share a namespace based on the origin (the tuple of a uniform resource locator) that they originate from, and web apps and traditional apps share a “l(fā)ocalhost” namespace, which is separate from th