UNITED STATES PATENT AND TRADEMARK OFFICE
`
`___________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`___________
`
`GOOGLE INC.
`Petitioner
`
`v.
`
`ALFONSO CIOFFI, MEGAN ELIZABETH ROZMAN,
`MELANIE ANN ROZMAN, AND MORGAN LEE ROZMAN
`Patent Owners
`
`___________
`
`Patent No. RE43,528
`___________
`
`DECLARATION OF DR. STEVEN M. BELLOVIN
`
`Google - Exhibit 1032, cover
`
`

`

`I, Steven M. Bellovin, Ph.D., declare as follows:
`
`1.
`
`I make this declaration based upon my own personal knowledge and,
`
`if called upon to testify, would testify competently to the matters stated herein.
`
`2.
`
`I am one of the authors of a paper entitled “Building a Secure Web
`
`Browser.” The paper was presented at the 2001 USENIX Annual Technical
`
`Conference in Boston, Massachusetts, in June 2001, and copies of the paper were
`
`available without restriction at that Conference. A true and correct copy of the
`
`paper is attached to this declaration as Exhibit A. I believe the paper was also
`
`published by USENIX on its website at approximately the same time.
`
`3.
`
`I am one of the authors of a paper entitled “Sub-Operating Systems:
`
`A New Approach to Application Security.” The paper was presented at the 10th
`
`ACM SIGOPS European Workshop in September 2002 in Saint-Emilion, France,
`
`and I believe that copies of the paper were available in the printed conference
`
`proceedings available at that Workshop. A true and correct copy of the paper is
`
`attached to this declaration as Exhibit B as it appeared in the printed conference
`
`proceedings, including remarks from the Chair and the Table of Contents showing
`
`that the paper started on page 108. I also published a longer version of the paper
`
`by December 2002 on my webpage at AT&T, where I worked at the time. I listed
`
`the paper along with other publications under the topic “Host and Internet
`
`Security,” naming all three co-authors.
`
`1
`
`Google - Exhibit 1032, page 1
`
`

`

`I declare that all statements made herein of my own knowledge are true and
`
`that all statements made on information and belief are believed to be true; and
`
`further that these statements were made with the knowledge that willful false
`
`statements and the like so made are punishable by fine or imprisonment, or both,
`
`under Section 1001 of Title 18 of the United States Code.
`
`Executed on November ___, 2016, in ____________, ________.
`
`
`
`
`_____________________________
`Steven M. Bellovin, Ph.D.
`
`2
`
`Google - Exhibit 1032, page 2
`
`

`

`Exhibit A
`
`Exhibit A
`
`Google - Exhibit 1032, page 3
`
`Google - Exhibit 1032, page 3
`
`

`

`USENIX Association
`
`Proceedings of the
`FREENIX Track:
`2001 USENIX Annual
`Technical Conference
`
`Boston, Massachusetts, USA
`June 25-30, 2001
`
`USENIX
`
`THE ADVANCED COMPUTING SYSTEMS ASSOCIATION
`
`For more information about the USENIX Association:
`All Rights Reserved
`© 2001 by The USENIX Association
`WWW: http://www.usenix.ora
`Email: office@usenix.org
`FAX: 1 510 548 5738
`Phone: 1 510 528 8649
`Rights to individual papers remain with the author or the author's employer.
`Permission is granted for noncommercial reproduction of the work for educational or research purposes.
`This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein.
`
`Google - Exhibit 1032, page 4
`
`

`

`Building a Secure Web Browser*
`
`Sotiris Ioannidis
`sotiris@dsl.cis.upenn.edu
`University of Pennsylvania
`
`Steven M. Bellovin
`smb@resear ch. att. com
`AT&T Labs Research
`
`Abstract
`
`Over the last several years, popular applications
`such as Microsoft Internet Explorer and Netscape
`Navigator have become prime targets of attacks.
`These applications are targeted because their func­
`tion is to process unauthenticated network data that
`often carry active content. The processing is done
`either by helper applications, or by the web browser
`itself. In both cases the software is often too com­
`plex to be bug free. To make matters worse, the
`underlying operating system can do very little to
`protect the users against such attacks since the soft­
`ware is running with the user’s privileges.
`
`We present the architecture of a secure browser, de­
`signed to handle attacks by incoming malicious ob­
`jects. Our design is based on an operating system
`that offers process-specific protection mechanisms.
`
`Keywords: Secure systems, web browser, process-
`specific protection.
`
`since they operate on untrusted data. These appli­
`cations which are often buggy [11], execute with the
`users privileges and can therefore compromise the
`security of the system. Furthermore the browsers
`also interpret code like JavaScript and VBScript [6],
`making the browser itself vulnerable 1.
`
`In this paper we present the architecture of a secure
`web browser. Our system is designed to address the
`problems that plague the popular Web browsers by
`using support offered by the operating system. We
`built our prototype on SubOS [12]. SubOS is an
`operating system that offers process-specific protec­
`tion mechanisms, which we will explain in Section
`3.
`
`The paper is organized as follows. In Section 2 we
`discuss the motivation behind this work. In Sec­
`tion 3 we give a brief background description of a
`SubOS-capable operating system. In Section 4 we
`present the architecture of our system. In Section 5
`we discuss related work, and finally we conclude in
`Section 6.
`
`1 Introduction
`
`2 Motivation
`
`In the current highly interconnected computing en­
`vironments, Web browsers are probably the most
`popular tool for receiving data over the internet.
`More often than not, the data come from unauthen­
`ticated sources that can potentially be malicious.
`Since the incoming data often carry active content
`that will be interpreted on the client machine, in
`many cases without the users knowledge, a number
`of attacks become possible.
`
`To interpret active content web browsers often rely
`on helper applications, that become security critical
`‘This work was supported by DARPA under Contract
`F39502-99-1-0512-MOD P0001.
`
`With the growth of the Internet, exchange of infor­
`mation over wide-area networks has become essen­
`tial for users. Web browsers, like Netscape Naviga­
`tor and Microsoft Internet explorer often automati­
`cally invoke helper application to handle the down­
`loaded object. In some cases, like in Perl scripts,
`they will query the user before executing it. In oth­
`ers, like in Postscript files or Java applets [10,15, 9],
`they will execute the content, possibly compromis­
`ing the security of the system. The former approach
`puts a lot of burden on the user, who more often
`than not is not particularly security conscious. In
`1 There are a number of hostile JavaScript and VBScript
`sites on the Web, easily found using search engines
`
`Google - Exhibit 1032, page 5
`
`

`

`the latter case the user is bypassed altogether and
`system security becomes dependent on the correct­
`ness of the Postscript or Applet viewer.
`
`It is also the case that seemingly inactive objects
`like Web pages are very much active and potentially
`dangerous. One example is JavaScript [6]programs
`which are executed within the security context of
`the page with which they were down-loaded, and
`they have restricted access to other resources within
`the browser. Security flaws exist in certain Web
`browsers that permit JavaScript programs to mon­
`itor a user’s browser activities beyond the security
`context of the page with which the program was
`down-loaded (CERT Advisory CA:97.20). It is obvi­
`ous that such behavior automatically compromises
`the user’s privacy and security.
`
`The lack of flexibility in modern operating systems
`is one of the main reasons security is compromised.
`The UNIX operating system, in particular, violates
`the principle of least privilege. The principle of least
`privilege states that a process should have access to
`the smallest number of objects necessary to accom­
`plish a given task. UNIX only supports two privilege
`levels: “root” and “any user”.
`
`To overcome this shortcoming, UNIX, can grant
`temporary privileges, namely setuid(2) (set user
`id) and setgid(2) (set group id). These commands
`allow a program’s user to gain the access rights of
`the program’s owner. However, special care must
`be taken any time these primitives are used, and as
`experience has shown a lack of sufficient caution is
`often exploited [13].
`
`Another technique used by UNIX is to change the
`apparent root of the file system using chroot(2).
`This causes the root of a file system hierarchy vis­
`ible to a process to be replaced by a subdirectory.
`One such application is the ftpd(8) daemon; it has
`full rights in a safe subdirectory, but it cannot ac­
`cess anything beyond that. This approach, however,
`is very limiting, and in the particular example com­
`mands such as ls(l) become unreachable and have
`to be replicated.
`
`These mechanisms are inadequate to handle the
`complex security needs of today’s applications. This
`forces a lot of access control and validity decisions
`to user-level software that runs with the full privi­
`leges of the invoking user. To overcome these short­
`comings applications such as Web browsers become
`responsible for accepting requests, granting permis-
`
`All this is what
`sions and managing resources,
`is traditionally done by operating systems. Web
`browsers consequently, because of their complexity
`as well as the lack of flexibility in the underlying
`security mechanisms, possess a number of security
`holes. Examples of such problems are numerous,
`e.g. JavaScript, malicious Postscript documents,
`etc.
`
`We wish to demonstrate how to build a secure
`browser, designed to handle attacks by incoming
`malicious objects, on top of an an operating system
`that offers process-specific protection mechanisms.
`
`3 SubOS-enabled Operating Systems
`
`SubOS is a process-specific protection mechanism,
`a more extensive discussion on SubOS can be
`found in [12]. Under SubOS any application (e.g.
`ghostscript, perl, etc.) that might operate on pos­
`sibly malicious objects (e.g. postscript files, perl
`scripts, etc.) behaves like an operating system, re­
`stricting their accesses to system resources. We are
`going to call these applications SubOS processes, or
`sub-processes in the rest of this paper. Figures 1
`and 2 demonstrate the difference between a regular
`and a SubOS-enabled operating system. The access
`rights for that object are determined by a sub-user
`id that is assigned to it when it is first accepted
`by the system. The sub-user id is a similar notion
`to the regular UNIX user id’s. In UNIX the user
`id determines what resources the user is allowed to
`have access to, in SubOS the sub-user id determines
`what resources the object is allowed to have access
`to. The advantage of using sub-user id’s is that we
`can identify individual objects with an immutable
`tag, which allows us to bind a set of access rights to
`them. This allows for finer grain per-object, access
`control, as opposed to per-user access control.
`
`The idea becomes clear if we look at the example
`shown in Figure 3. Let us assume that our un­
`trusted object is a postscript file foo.ps. To that
`object we have associated a sub-user id, as we will
`discuss in Section 3.1. Foo.ps initially is an inactive
`object in the file system. While it remains inac­
`tive it poses no threat to the security of the system.
`However the moment gs (1) opens it, and starts exe­
`cuting its code, foo.ps becomes active, and automat­
`ically a possible danger to the system. To contain
`this threat, the applications that open untrusted ob-
`
`Google - Exhibit 1032, page 6
`
`

`

`Applications
`
`_ «
`a 1
`-S
`"O ^
`C OX)
`
`cO C11 O (U
`
`u> d
`
`O <L>
`o CdS “
`o-.S
`■p s
`fe.53
`> "
`
`a.
`|S
`& Of)
`CGC
`c
`c
`
`Operating System
`
`Unprotected Spact
`
`Resources
`(CPU, Memory, Disk, Network, etc.)
`
`Protected Space
`
`Figure 1: User applications executing on an operating system maintain the user privileges, allowing
`them almost full access to the underlying operating system.
`
`jects, inherit the sub-user id of that objects, and are
`hereafter bound to the permissions and privileges
`dictated by that sub-user id.
`
`There is a strong analogy here to the standard UNIX
`setuid(2) mechanism. When a suitably-marked
`file is executed, the process acquires the access rights
`of the owner. With SubOS, suitably-marked pro­
`cesses acquire the access rights of the owner of the
`files that they open. In this case, of course, the new
`rights are never greater than those the process had
`before.
`
`The advantages of our approach become apparent
`if we consider the alternative methods of ensuring
`that a malicious object does not harm the system.
`Again using our postscript example we can execute
`foo.ps inside a safe interpreter that will limit its ac­
`cess to the underlying file system. There are how­
`ever a number of examples on how relying on safe
`languages fails [11]. We could execute the postscript
`interpreter inside a sandbox using chroot(2), but
`this will prohibit it from accessing font files that it
`might need. Finally we could read the postscript
`code and make sure that it does not include any
`malicious commands, but this is impractical.
`
`Our method provides transparency to the user and
`increased security since every data object has its ac­
`cess rights bound to its identity, preventing it from
`harming the system.
`
`File
`foo.ps
`sub-user id
`
`Process
`gs foo.ps
`sub-user id ^
`
`File
`foo.ps
`sub-user id
`
`In the left part of the Figure we see
`Figure 3:
`an object, in this case a postscript file foo.ps,
`with its associated sub—user id. The moment the
`ghostscript application opens file Foo.ps, it turns
`into a SubOS process and it inherits the sub—user
`id that was associated with the untrusted object.
`From now on, this process has the permissions
`and privileges associated with this sub—user id.
`
`3.1 Security Mechanism Enforcement
`
`As we mentioned earlier in Section 3, every time
`the system accepts an incoming object it associates
`a sub-user id with it, depending on the credentials
`the object carries. The sub-user id is permanently
`saved in the Inode of the file that holds that object,
`which is now its immutable identity in the system
`and specifies what permissions it will have. It has
`essentially the same functionality as a UNIX user
`
`Google - Exhibit 1032, page 7
`
`

`

`Applications
`
`=5 1
`•s s>
`“C 03 C op
`I IO 03u g
`
`O <L>
`8 «
`p s
`■O ^
`0-2
`£ >
`
`$
`
`CL
`
`<5 Sc« _Is
`
`O bO
`CQC
`C
`c
`
`Unprotected Space
`
`Operating System
`
`co
`O
`£
`
`co
`O
`
`00
`
`oo
`O
`JO
`00
`
`Resources
`(CPU, Memory, Disk, Network, etc.)
`
`Protected Space
`
`Figure 2: Under SubOS enabled operating systems user applications that “touch” possibly malicious
`objects no longer maintain the user access rights, and only get restricted access to the underlying
`system.
`
`id. One can view this as the equivalent of a user
`logging in to the system.
`
`Figure 4 shows the equivalence of the two mecha­
`nisms. In the top part of the figure we see the regu­
`lar process of a user Bar logging in a UNIX system
`Foo and getting a user id. In the same way, objects
`that enter the system through ftp, mail, etc., “log
`in” and are assigned sub-user id’s based on their
`(often cryptographically-verified) source.
`
`4 The Browser Architecture
`
`4.1 The Threat
`
`The use of Java, JavaScript and VBScript in HTML
`pages is becoming ever more popular, furthermore
`HTML provides support for other scripting lan­
`guages with the use of the <SCRIPT> tag [3]. Even
`though this functionality is primarily intended to
`enhance the capabilities of web pages and the “surf­
`ing experience” of the user, it is often used to attack
`unsuspecting hosts.
`
`Even worse, the site or host is vulnerable even if
`the browser is behind the firewall and the document
`is a “secure” HTTPS-based document. JavaScript
`programs are executed within the security con­
`text of the page in which they were down-loaded,
`
`Host Foo
`
`Login User Bar
`
`Password UNIX password
`—user id
`
`Host Foo
`
`ftp, mail, Object Bar. {ps,html,...}
`Web, etc.
`Password Cryptographic Token
`sub-user id
`
`Figure 4: In the top part of the Figure we see the
`regular process of a user Bar logging in a UNIX
`system Foo and getting a user id. In the same
`way objects that enter the system through ftp,
`mail, etc., “log in” using a cryptographic token,
`and are assigned sub-user id’s.
`
`and should have restricted access to other re­
`sources within the browser. Some browsers running
`JavaScript may, in turn, have security flaws that
`allow the JavaScript program to monitor a user’s
`browser more than what is considered safe or se­
`cure. In addition, it may be difficult or impossible
`for the browser user to determine if the program
`is transmitting information back to the web server.
`
`Google - Exhibit 1032, page 8
`
`

`

`For instance, among other functions, JavaScript is
`able to monitor a user’s browser activity by:
`
`2. Web pages that carry active content that is in­
`terpreted by the browser.
`
`• Observing the URLs of visited documents as
`well as bookmarks.
`• Observing the data filled into HTML forms (in­
`cluding passwords).
`• Observing the values of cookies (that might
`hold critical information).
`
`In Java the user may or may not be informed that an
`applet is being down-loaded into their browser. The
`real shock comes when a user inadvertently down­
`loads a hostile applet. There are many different
`things hostile applets can do to wreak havoc on your
`system. Among a few of the most noteworthy are
`the following:
`
`• Reveal information about your machine (e.g.
`details about passwords or structure of your
`system).
`• Allocate resources to the point your machine
`“locks up” (i.e. denial of service attacks).
`• Delete or alter files.
`• Be just plain annoying (e.g. popping countless
`windows).
`
`Hostile applets have also been known to have the ca­
`pability to contact machines behind firewalls, send
`off a listing of a user’s directories, track a user’s ac­
`tions through the web, generate machine code, make
`directories readable and writable, and send off email
`without intention 2.
`
`4.2 Modular Approach
`
`In our architecture we address the two security prob­
`lems of Web browsers:
`
`1. Helper applications running with the user’s
`privileges.
`2There are a number of web sites that list hostile applets,
`JavaScript and VBScript, readily available for anyone inter­
`ested in launching an attack.
`
`To address these problems we will use the mech­
`anisms provided by the SubOS-capable operating
`system, as well as a modular Web browser archi­
`tecture. We divide the Web browser into three
`parts, according to its functionality. The first part
`is responsible for down-loading objects over the net­
`work, the second is responsible for displaying the
`content, and the last is a set of helper applica­
`tions/interpreters used to process the content of the
`down-loaded objects. The design is presented in
`Figure 5
`
`Browser Log-in Daemon
`
`>
`
`Browser Display
`
`Browser Interpreter
`
`Browser Interpreter
`
`Figure 5: The Web browser is comprised of three
`parts. The first part is responsible for down­
`loading objects from the net and assigning sub­
`user id’s to them. The second provides the user
`interface of the browser. Finally the third is a set
`of processes that interpret the active code that
`is carried by the incoming objects.
`
`We decided against using an existing Web browser
`since that would require significant modification to
`its architecture. Down-loading and authentication
`of objects could be easily achieved by using a proxy,
`however execution of embedded code in HTML web
`pages would be a lot more challenging, since it would
`have to execute in a separate address space to main­
`tain its security properties, as we discussed in Sec­
`tion 3.
`
`4.2.1 Browser Log-in Daemon
`
`Every object that is down-loaded by our browser
`log-in daemon is assigned a sub-user id, which is
`bound to some permissions, and is then stored in the
`
`Google - Exhibit 1032, page 9
`
`

`

`file system. Assignment of sub-user id’s is similar to
`the log in mechanism of UNIX. Objects that carry
`certificates are given more permissions than unau­
`thenticated objects. For example an authenticated
`object might get access to /home/user_f:oobar, net­
`work access and unlimited resources, whereas an
`unauthenticated objects might only get access to
`/tmp with no access to the network and limited CPU
`time and memory allocation.
`
`In the current implementation we use the URL ad­
`dress is used to select the sub-user id that will be
`assigned to the down-loaded object. This approach
`of course is not really secure, ideally we should use
`some sort of cryptographic token (e.g. a certificate)
`that is carried along with the down-loaded object.
`
`4.2.2 Browser Display Daemon
`
`The display daemon is responsible for providing the
`user interface of the our Web browser. It can make
`requests to the log-in daemon to down-load files, it
`is responsible for spawning interpreters to handle
`the incoming objects, and display HTML.
`
`4.2.3 Browser Interpreter Daemon
`
`The final part of our web browser is the set of in­
`terpreter daemons. These processes have dual func­
`tionality; they interpret HTML along with any pos­
`sible active content embedded in the web page, and
`they execute the helper applications that handle in­
`coming objects such as Perl, Postscript, etc.
`
`Objects that are normally handled by helper appli­
`cations are also assigned sub-user id’s by the log­
`in daemon, the same way as ordinary web pages.
`When they are interpreted they are bound to the
`permissions of that sub-user id. This way users
`don’t need to be queried about every arbitrary ob­
`ject they down-load of the net and also don’t have
`to worry about executing possibly malicious code on
`their machine.
`
`When the interpreter daemon encounters active
`code embedded in a web page (by encountering an
`<APPLET> or <SCRIPT> tag) it spawns a process to
`interpret the Java, JavaScript [1], or Perl code. The
`new process inherits the permissions of the parent
`process so the active code can never escape it’s sand­
`box.
`
`5 Related Work
`
`Web browser security is topic that has received a
`great deal of attention since its so crucial in today’s
`highly interconnected computing. However there
`have not been any satisfactory solutions so far. The
`primary proposed solution is secure interpreters for
`JavaScript, VBScript, Java, etc. [14, 15, 17, 10, 9].
`Such solutions fail because of their complexity. The
`more complex the implementation, the more likely
`it is to have bugs. Furthermore they don’t address
`the issue of other helper applications like Perl or
`Tel. When they are invoked, the user is asked to
`give a blanket “go” “no-go” response, and this puts
`a lot of burden to the user.
`
`Another language related technique used for ensur­
`ing security is code verification. This approach uses
`proof-carrying code [16] to demonstrate the security
`properties of the object. This means that the object
`needs to carry with it a formal proof of its prop­
`erties; this proof can be used by the system that
`accepts it to ensure that it is not malicious. Code
`verification is very limiting since it is hard to cre­
`ate such proofs. Furthermore, it does not scale well;
`imagine creating a formal proof for every Web page.
`
`A different approach relies on the notion of sys­
`tem call interception, as used by systems such as
`TRON [5], MAPbox [4], Software Wrappers [7] and
`Janus [8]. TRON and Software Wrappers enforce
`capabilities by using system call wrappers compiled
`into the operating system kernel. The syscall ta­
`ble is modified to route control to the appropriate
`TRON wrapper for each system call. The wrappers
`are responsible for ensuring that the process that
`invoked the system call has the necessary permis­
`sions. The Janus and MAPbox systems implement
`a user-level system call interception mechanism. It
`is aimed at confining helper applications (such as
`those launched by Web browsers) so that they are
`restricted in their use of system calls. To accom­
`plish this they use ptrace(2) and the /proc file
`system, which allows their tracer to register a call­
`back that is executed whenever the tracee issues a
`system call. These systems are the most related
`to our work; however, our system differs in a ma­
`jor point. We view every object as a separate user,
`each with its own sub-user id and access rights to
`the system resources. This sub-user id is attached
`to every incoming object when it is accepted by the
`system, and stays with it throughout it’s life, mak­
`ing it impossible for malicious objects to escape.
`
`Google - Exhibit 1032, page 10
`
`

`

`6 Conclusions
`
`7 Acknowledgments
`
`We have presented the architecture of a secure web
`browser, that protects against malicious incoming
`objects. We have implemented a first version of our
`prototype on a SubOS-capable OpenBSD 2.8 [2] op­
`erating system using Perl.
`
`There are several advantages in our modular archi­
`tecture versus the monolithic architecture of popu­
`lar Web browsers, such as Netscape Navigator and
`Microsoft Internet Explorer. Our design adds a
`stage of authentication before any incoming object
`is processed. The burden of access control is moved
`from the browser and its helper applications, to the
`operating system, allowing for a simpler and there­
`fore more secure design. Finally the user is not in­
`volved in the processing of incoming objects, and
`therefore cannot be tricked into executing hostile
`code. Presently however, our architecture requires
`that the operating system provides a data centric
`protection mechanism, that associates permissions
`and privileges to data objects. This limits us to
`our experimental SubOS-enabled OpenBSD operat­
`ing system.
`
`There are still some things that remain to be added
`to our prototype browser in order to offer more com­
`plete functionality:
`
`• We currently don’t support frames. Frames re­
`quire special handling since each frame consists
`of an HTML document with possibly individ­
`ual security properties. In future versions of
`our browser we will add this functionality to
`the browser display daemon.
`
`• Only a subset of HTML was implemented so
`there are a number of tags that need to be
`added, along with their possible variables.
`
`• We want to expand the <SCRIPT> tag to deal
`with additional embedded scripting languages
`other than JavaScript and Perl.
`
`• Finally we need to have some kind of secure au­
`thentication mechanism for the browser log-in
`daemon. The possible solutions we are consid­
`ering are either an additional tag that carries
`a certificate in the down-loaded web page, or a
`certificate attached to the HTTP request.
`
`We would like to thank Jonathan M. Smith for
`his useful comments and guidance throughout the
`We also like to thank
`course of this work,
`the FREENIX 2001 anonymous reviewers and our
`“shepherd” Ken Coar for their comments and sug­
`gestions on improving this paper.
`
`References
`
`Interpreter.
`
`Consortium.
`
`[1] NJS
`JavaScript
`http: //www.bbassett.net/njs/.
`[2] The OpenBSD Operating System.
`http://www.openbsd.org/.
`[3] World Wide Web
`http://www.w3.org/.
`[4] Anurag Acharya and Mandar Raje. Map-
`box: Using parameterized behavior classes to
`confine applications. In Proceedings of the
`2000 USENIX Security Symposium, pages 1­
`17, Denver, CO, August 2000.
`[5] Andrew Berman, Virgil Bourassa, and Erik
`Selberg. TRON: Process-Specific File Pro­
`tection for the UNIX Operating System. In
`USENIX 1995 Technical Conference, New Or­
`leans, Louisiana, January 1995.
`[6] David Flanagan. JavaScript The Definitive
`Guide. O’Reilly, 1998.
`'
`
`[7] Tim Fraser, Lee Badger, and Mark Feldman.
`Hardening COTS Software with Generic Soft­
`ware Wrappers. In Proceedings of the IEEE
`Symposium on Security and Privacy, Oakland,
`CA, May 1999.
`[8] Ian Goldberg, David Wagner, Randi Thomas,
`and Eric A. Brewer. A Secure Environment
`for Untrusted Helper Applications. In USENIX
`1996 Technical Conference, 1996.
`[9] Li Gong. Inside Java 2 Platform, Security.
`Addison-Wesley, 1999.
`[10] James Gosling, Bill Joy, and Guy Steele. The
`Java Language Specification. Addison Wesley,
`Reading, 1996.
`[11] http://www.cert.org/advisories/.
`
`Google - Exhibit 1032, page 11
`
`

`

`[12] Sotiris Ioannidis and Steven M. Bellovin. Sub­
`Operating Systems: A New Approach to Appli­
`cation Security. Technical Report MS-CIS-01-
`06, University of Pennsylvania, February 2000.
`[13] R. Kaplan. SUID and SGID Based Attacks
`on UNIX: a Look at One Form of then Use
`and Abuse of Privileges. Computer Security
`Journal, 9(l):73-7, 1993.
`[14] Jacob Y. Levy, Laurent Demailly, John K.
`Ousterhout, and Brent B. Welch. The Safe-
`Tcl Security Model. In USENIX 1998 Annual
`Technical Conference, New Orleans, Louisiana,
`June 1998.
`[15] Gary McGraw and Edward W. Felten. Java
`Security: hostile applets, holes and antidotes.
`Wiley, New York, NY, 1997.
`[16] G. C. Necula and P. Lee. Safe, Untrusted
`Agents using Proof-Carrying Code. In Lec­
`ture Notes in Computer Science Special Issue
`on Mobile Agents, October 1997.
`[17] Dan S. Wallach, Dirk Balfanz, Drew Dean, and
`Edward W. Felten. Extensible Security Archi­
`tectures for Java. In Proceedings of the 16th
`ACM Symposium on Operating Systems Prin­
`ciples, October 1997.
`
`Google - Exhibit 1032, page 12
`
`

`

`Exhibit B
`
`Exhibit B
`
`Google - Exhibit 1032, page 13
`
`Google - Exhibit 1032, page 13
`
`

`

`A few words of welcome from the General Chair
`It is a great pleasure to have the SIGOPS EW in France again, 10 years after
`the Mont Saint-Michel workshop. While Mont Saint-Michel is surrounded by
`the sea, Saint-Emilion is amidst miles of vineyards. There is no tide here, even
`if one may refer to the level of wine in the bottles... Still, I am sure that Emilion
`will do as well as Michel did in inspiring fruitful discussions among us. In the
`event of a failure of the saint’s spirit, I am sure that the wine cellar located
`underneath the meeting room in “Le chateau la Couspaude”, a Saint-Emilion
`grand cru class´e, will be an excellent backup.
`“Can we really depend on an OS?”, “In vino veritas”, Baccus would have
`certainly answered.
`Thank you for coming to EW2002 and have a very enriching workshop,
`
`Gilles Muller
`EW2002 General Chair
`Nantes, July 2002
`
`A few words of welcome from the Program Chair
`First, thanks to all the authors for their essential efforts to make this workshop
`successful; without good papers—no workshop. We had a total of 50 submissions
`which is slightly up from the previous workshop. Of these the PC selected
`sixteen for presentations; thanks to the PC for their work.
`I used a simple system for submission: merely e-mail. This, unfortunately,
`does not work perfectly; I “lost” several papers which delayed their review—
`apologies to those authors that had to wait past the notification deadline.
`The European Workshop is usually held in beautiful locations where the re-
`laxed atmosphere can foster fruitful discussions between the participants. Gilles
`Muller has found a pearl of a location—and not just for wine lovers! And he
`has put in a tremendous effort to do the arrangements. I hope that you will all
`participate actively.
`The theme of the workshop “Can we really depend on an OS?” has been
`viewed from many different points as the presentations will show. The panel
`discussion will attack the issues head-on.
`Finally, thanks goes to Jean-Marc Menaud for his help with registration and
`to Robert Bialek and Christian Boesgaard for their efforts in producing the
`proceedings.
`Have fun!
`
`Eric Jul
`EW2002 Program Chair
`Copenhagen, July 2002
`
`Google - Exhibit 1032, page 14
`
`

`

`Contents
`
`1 List of Papers
`
`2 List of extended abstracts
`
`3 List of authors
`
`3
`
`4
`
`6
`
`9
`4 Session Papers
`9
`Session 1. Instrumentation . . . . . . . . . . . . . . . . . . . . . .
`30
`Session 2. Operating Systems . . . . . . . . . . . . . . . . . . . .
`44
`Session 3. Theory . . . . . . . . . . . . . . . . . . . . . . . . . . .
`62
`Session 4. Robust Service . . . . . . . . . . . . . . . . . . . . . .
`78
`Session 5. Security & Authentication . . . . . . . . . . . . . . . .
`Session 6. Operating System’s Structures
`. . . . . . . . . . . . . 101
`Session 7. Peer-to-Peer . . . . . . . . . . . . . . . . . . . . . . . . 116
`
`5 Extended Abstracts
`
`146
`
`2
`
`Google - Exhibit 1032, page 15
`
`

`

`Author
`Yvonne Coady, Gregor Kiczales
`
`page
`78
`
`Julia L. Lawall, Gilles Muller, Lu-
`ciano Porto Barreto
`Andrew Whitaker, Marianne
`Shaw, Steven D. Gribble
`Timothy L. Harris
`
`Ayalvadi J. Ganesh, Anne-Marie
`Kermarrec, Laurent Massoulie
`Timothy Roscoe, Richard Mortier,
`Paul Jardetzky, Steven Hand
`Michael M. Swift, Steven Martin,
`Henry M. Levy, Susan G. Eggers
`Miguel Castro, Peter Druschel,
`Antony Rowstron
`Matt Welsh, David Culler
`
`54
`
`9
`
`38
`
`133
`
`30
`
`101
`
`140
`
`62
`
`70
`
`49
`
`16
`125
`
`44
`
`108
`
`87
`
`2