1 Introduction
Rationale and Origins. Web browsers have in fact become operating systems for a myriad of webbased applications. Given the enormous user base and the massive increase in webbased application areas, browsers have for a long time been a prime target for security attacks, with a seemingly unending sequence of browser security violations. One key reason for this problematic state of affairs is the enormous size (millions of lines of code) and sheer complexity of conventional browsers, which make their formal verification a daunting task. An early effort to substantially improve browser security by formal methods was jointly carried out by researchers at Microsoft Research and the University of Illinois at UrbanaChampaign (UIUC), who formally specified Internet Explorer (IE) in Maude [maudebook], and model checked that formalization finding 13 new types of unknown address bar or status bar spoofing attacks in it [IEmaudeanalysis]. To avoid attacks on those newly found vulnerabilities, they were all corrected in IE before [IEmaudeanalysis] was published. But the research in [IEmaudeanalysis] just uncovered some kinds of possible attacks, and the sheer size and complexity of IE made full verification unfeasible. This stimulated a team of systems and formal methods researchers at UIUC to ask the following question: could formal methods be used from the very beginning in the design of a secure browser with a very small trusted code base (TCB) whose design could be verified? The answer given to this question was the Maudebased design, model checking verification, and implementation of the IBOS Browser cum operating system, [DBLP:conf/osdi/TangMK10, tangthesis, sassethesis, DBLP:conf/facs2/SasseKMT12], with a 42K line trusted code base (TCB), several orders of magnitude smaller than the TCBs of commodity browsers.
Why this Work. As further explained in Section 6, only a model checking verification of the IBOS security properties relying on a handproof abstraction argument for its full applicability was possible at the time IBOS was developed [sassethesis, DBLP:conf/facs2/SasseKMT12, rochathesis]. A subsequent attempt at a full deductive verification of IBOS in [rochathesis] had to be abandoned due to the generation of thousands of proof obligations. In retrospect, this is not surprising for two reasons. (1) Many of the symbolic techniques needed to scale up the IBOS deductive verification effort, including variant unification and narrowing [variantJLAP], ordersorted congruence closure module axioms [DBLP:conf/fossacs/Meseguer16], and variantbased satisfiability [varsatscp, skeirikmeseguervarsatJLAMP], did not exist at the time. In the meantime, those symbolic techniques have been developed and implemented in Maude. (2) Also missing was a program logic generalizing Hoare logic for Maude specifications in which properties of concurrent systems specified in Maude could be specified and verified. This has been recently addressed with the development of a constructorbased reachability logic for rewrite theories in [DBLP:conf/lopstr/SkeirikSM17, DBLP:journals/fuin/SkeirikSM20], which extends prior reachability logic research on verification of conventional programs using K in [DBLP:conf/fm/RosuS12, DBLP:conf/oopsla/RosuS12, DBLP:conf/rta/StefanescuCMMSR14, DBLP:conf/oopsla/StefanescuPYLR16]. In fact, what has made possible the deductive proof of the IBOS security properties presented in this paper is precisely the combination of the strengths from (1) and (2) within the reachability logic theorem prover that we have developed for carrying out such a proof. Implicit in both (1) and (2) are two important proof obligations. First, both our symbolic reasoning and reachability logic engines take as input a rewrite theory . However, the correctness of the associated deductions depends on the theory being suitable for symbolic reachability analysis, i.e., its equations should be ground convergent and sufficiently complete; therefore, these properties are proof obligations that must be discharged. Second, the previous modelcheckingbased verification that the IBOS design satisfies certain security properties [sassethesis, DBLP:conf/facs2/SasseKMT12] was based on an invariant . Our deductive verification uses a slightly different invariant that is also inductive (as explained in Section 3). Thus, we require that is at least as strong as or stronger than to ensure that our specification of the IBOS security properties does not miss any cases covered by the prior work. Both of these important proof obligations have been fully checked as explained in [skeirikthesis]. Last, but not least, as we further explain in Section 6, the IBOS browser security goals remain as relevant and promising today as when IBOS was first developed, and this work bring us closer to achieving those goals.
Main Contributions. They include:

The first full deductive verification of the IBOS browser as explained above.

A general modular proof methodology for scaling up reachability logic proofs of objectbased distributed systems that has been invaluable for verifying IBOS, but has a much wider applicability to general distributed system verification.

A substantial and useful case study that can be of help to other researchers interested in both browser verification and distributed system verification.

New capabilities of the reachability logic prover, which in the course of this research has evolved from the original prototype reported in [DBLP:conf/lopstr/SkeirikSM17] to a first prover version to be released in the near future.
Plan of the Paper. Preliminaries are gathered in Section 2. Reachability Logic and invariant verification are presented in Section 3. IBOS, its rewriting logic Maude specification, and the specification of its security properties are explained in Section 4. The deductive proof of those IBOS properties and the modular proof methodology used are described in Section 5. Section 6 discusses related work and concludes the paper.
2 Preliminaries on Equational and Rewriting Logic
We present some preliminaries on ordersorted equational logic and rewriting logic. The material is adapted from [osa1, tarquinia, 20years].
OrderSorted Equational Logic. We assume the basic notions of ordersorted (abbreviated OS) signature , term , algebra , and homomorphism [osa1, tarquinia]. Intuitively, defines a partially ordered set of sorts , which are interpreted in a algebra with carrier family of sets as sort containments. For example, if we have a sort inclusion , then we must have . An operator, say , in may have several related typings, e.g., and , whose interpretations in an algebra must agree when restricted to subsorts. The OS algebras over signature and their homomorphisms form a category . Furthermore, under mild syntactic conditions on , the term algebra is initial [tarquinia]; all signatures are assumed to satisfy these conditions.
An sorted set of variables, satisfies , and the variables in are always assumed disjoint from all constants in . The term algebra on variables , , is the initial algebra for the signature obtained by adding to the variables as extra constants. Given a algebra , an assignment is an sorted function mapping each variable to a value for each . Each such assignment uniquely extends to a homomorphism , so that if , then . In particular, for , an assignment is called a substitution and uniquely extends to a homomorphism . Define and .
We assume familiarity with the language of firstorder logic with equality. In particular, given a formula , we assume familiarity with the satisfaction relation for a algebra and assignment for the free variables of . Then, is valid in , denoted , iff , and is satisfiable in iff . Let (resp. ) denote the set of formulas (resp. quantifier free formulas).
An OS equational theory is a pair , with a set of (possibly conditional) equations. denotes the full subcategory of with objects those such that , called the algebras. The inference system in [tarquinia] is sound and complete for OS equational deduction. equality, i.e., provability , is written . has an initial algebra [tarquinia]. Given a system of equations , an unifier for is a substitution such that , ; an unification algorithm for generates a complete set of unifiers for any system in the sense that, up to equality, any unifier of is a substitution instance of some unifier .
Rewriting Logic. A rewrite theory , with an OSequational theory with equations and structural axioms (typically any combination of associativity, commutativity, and identity), and a collection of rewrite rules, specifies a concurrent system whose states are elements of the initial algebra and whose concurrent transitions are specified by the rewrite rules . The concurrent system thus specified is the initial reachability model associated to [brunimeseguertcs, 20years].
Maude [maudebook] is a declarative programming language whose programs are exactly rewrite theories. To be executable in Maude, a rewrite theory should satisfy some executability conditions spelled out below. Recall the notation for term positions, subterms, and replacement from [dershowitzjouannaud]: (i) positions in a term are marked by strings specifying a path from the root, (ii) denotes the subterm of term at position , and (iii) denotes the result of replacing subterm at position by .
Definition 1
An executable rewrite theory is a 3tuple with an OS equational theory with possibly conditional and a set of possibly conditional rewrite rules, i.e., sequents , with for some , and a quantifierfree formula. We further assume that:

is a collection of associativity and/or commutativity and/or identity axioms and is preregular [maudebook].

Equations , oriented as rewrite rules , are convergent modulo [DBLP:journals/jlp/LucasM16].

Rules are ground coherent with the equations modulo [DBLP:journals/jlp/DuranM12].
The onestep rewrite relation holds iff there is a rule , a ground substitution with the rule’s variables, and position where , , and . Let denote the reflexivetransitive closure of the rewrite relation .
Intuitively, conditions (1)–(2) ensure that the initial algebra is isomorphic to the canonical term algebra , whose elements are equivalence classes of canonical ground terms, where is the canonical form of a term , denoted , iff: (i) , and (ii) . By convergent modulo , is unique up to equality [DBLP:journals/jlp/LucasM16]. Adding (3) ensures that “computing canonical forms before performing rewriting” is a complete strategy for rewriting with the rules module equations . That is, if and , then there exists a such that and . We refer to [20years, DBLP:journals/jlp/LucasM16, DBLP:journals/jlp/DuranM12] for more details.
Conditions (1)–(3) allow a simple and intuitive description of the initial reachability model [brunimeseguertcs] of as the canonical reachability model whose states are the elements of the canonical term algebra , and where the onestep transition relation holds iff and . Finally, if via rule and a ground substitution , then checking if condition holds is decidable by reducing terms in to canonical form.
An OSsubsignature is called a constructor subsignature for an OS equational theory where is convergent modulo iff . Furthermore, the constructors are then called free modulo axioms iff, as sorted sets, . This assumption gives a particularly simple description of the states of the canonical reachability model as equivalence classes of ground terms. As explained in Section 3, this simple constructorbased description is systematically exploited in reachability logic.
An executable rewrite theory with constructor subsignature is called topmost iff the poset of sorts has a maximal element, call it , such that: (i) for all rules , ; and (ii) for any in with we have , . This ensures that if , and , then all rewrites happen at the top position . This topmost requirement is easy to achieve in practice. In particular, it can always be achieved for objectbased rewrite theories, which we explain next.
ObjectBased Rewrite Theories. Most distributed systems, including the IBOS browser, can be naturally modeled by objectbased rewrite theories. We give here a brief introduction and refer to [ooconc, maudebook] for more details. The distributed state of an objectbased system, called a configuration, is modeled as a multiset or “soup” of objects and messages built up by an associativecommutative binary multiset union operator (with juxtaposition syntax) with identity . The sort has two subsorts: a sort of objects and a sort of messages “traveling” in the configuration from a sender object to a receiver object. The syntax for messages is userdefinable, but it is convenient to adopt a conventional syntax for objects as recordlike structures of the form: , where is the object’s name or object identifier, belonging to a subsort of a general sort , and is a set of object atributes of sort built with an associativecommutative union operator , with as identity element and with . Each is a constructor operator so that the data value has sort
. Objects can be classified in
object classes, so that a class has an associated subsort for its object identifiers and associated attribute constructors , . Usually, a configuration may have many objects of the same class, each with a different object identifier; but some classes (e.g., the class in IBOS) are singleton classes, so that only one object of that class, with a fixed name, will apear in a configuration. Another example in the IBOS specification is the singleton class . The single display object represents the rendering of the web page shown to the user and has the form: , where the activeTab attribute constructor contains a reference to the web process that the user has selected (each tab corresponds to a different web process) and the displayContent constructor encapsulates the web page content currently shown on the display. Not all configurations of objects and messages are sensible. A configuration is wellformed iff it satisfies the following two requirements: (i) unique object identifiers: each object has a unique name different from all other object names; and (ii) uniqueness of object attributes: within an object, each object attribute appears only once; for example, an object like is nonsensical.The rewrite rules of an objectbased rewrite theory have the general form , where and are terms of sort . Intuitively, is a pattern describing a local fragment of the overall configuration, so that a substitution instance describing a concrete such fragment (e.g., two objects, or an object and a message) can be rewritten to a new subfragment , provided the rule’s condition holds (see Section 4.1 for an example rule). Classes can be structured in multiple inheritance hierarchies, where a subclass of class , denoted , may have additional attributes and has a subsort for its object identifiers. By using extra variables of sort for “any extra attributes” that may appear in a subclass of any object in the lefthand side patterns of a rule, rewrite rules can be automatically inherited by subclasses [ooconc]. Furthermore, a subclass may have extra rules, which may modify both its superclass attributes and its additional attributes.
An objectbased rewrite theory can easily be made topmost as follows: (i) we add a fresh now sort and an “encapsulation operator,” say, , and (ii) we trasform each rule into the rule , where is a fresh variable of sort modeling “the rest of the configuration,” which could be empty by the identity axiom for .
3 ConstructorBased Reachability Logic
Constructorbased reachability logic [DBLP:conf/lopstr/SkeirikSM17, DBLP:journals/fuin/SkeirikSM20] is a partial correctness logic generalizing Hoare logic in the following sense. In Hoare logic we have state predicates and formulas are Hoare triples where is the precondition, is the postcondition, and is the program we are reasoning about. Since a Maude program is a rewrite theory , a Hoare triple in Maude has the form , with the expected partial correctness semantics. But we can be more general and consider reachability logic formulas of the form: , with the precondition (as in Hoare logic) but with what we call the formula’s midcondition. That is, need not hold at the end of a terminating computation, as in Hoare logic, but just somewhere in the middle of such a computation. A topmost rewrite theory satisfies , written , iff along any terminating computation from an initial state satisfying there is some intermediate state satisfying . More precisely:
Definition 2
Let be topmost with top sort and with free constructors modulo , and let and be state predicates for states of sort , so that and denote the respective subsets of defined by and . Furthermore, let be a state predicate of terminating states so that , where . Then, a reachability formula holds for the canonical reachability model of relative to in the all paths satisfaction relation, denoted , iff for every sequence with and there exists , such that .
When , we abbreviate the relation to just .
We can define the satisfaction of a Hoare triple as syntactic sugar for the satisfaction relation . As explained in [DBLP:journals/fuin/SkeirikSM20], the case of a Hoare logic for an imperative programming language is obtained as syntactic sugar for a special class of reachability logic formulas for a rewrite theory giving a rewriting logic semantics to the programming language .
But in what sense is such a reachability logic constructorbased? In the precise sense that the state predicates used in the logic are constrained constructor pattern predicates that exploit for symbolic purposes the extreme simplicity of the constructor theory , which is much simpler than the equational theory .
Definition 3
Let be convergent modulo and sufficiently complete with respect to , i.e., . A constrained constructor pattern is an expression such that . The set of constrained constructor pattern predicates is defined inductively over by adding and closing under () and (). We let capital letters range over . The semantics of is the subset such that:

,

,

= , and

= .
For any sort , let where iff each subpattern of has . is normal if it has no subpattern of the form . If has a finitary unification algorithm, normalization is effectively computable by (disjoint) unification [DBLP:conf/lopstr/SkeirikSM17, DBLP:journals/fuin/SkeirikSM20].
We can now fully specify our constructorbased reachability logic: it is a reachability logic for topmost rewrite theories with top sort and with free constructors modulo whose set of state predicate formulas is .
Reachability Logic Proof Rules [DBLP:conf/lopstr/SkeirikSM17, DBLP:journals/fuin/SkeirikSM20]. We review our proof system for reachability logic that was proved sound with respect to the allpaths satisfaction relation in [DBLP:conf/lopstr/SkeirikSM17, DBLP:journals/fuin/SkeirikSM20]. The proof rules derive sequents of the form , where and are finite sets of reachability formulas, , and reachability formula is normalized. Formulas in are called axioms; those in are called circularities. The proof system has three rules: Step, Axiom, and Subsumption as well as derived rules Case, Split, and Substitution. See the brief overview in Table 1. The derived rules are explained in Appendix 0.A.
Assumptions:
1. is suff. comp. w.r.t.
2.
Name  Rule  Condition 

Step  
Axiom  
Sub. 
,
This inference system has been mechanized using the Maude rewriting engine [DBLP:conf/lopstr/SkeirikSM17, DBLP:journals/fuin/SkeirikSM20]. Let us say a few words about its automation. The Step rule can be automated by narrowing, i.e., symbolic rewriting where the lefthand side of a rewrite rule , instead of being matched by a term to be rewritten, only unifies with it. Assuming has a finitary unification algorithm, the narrowing relation lifted to constrained constructor patterns is decidable. The Axiom and Subsumption rules require automating a constrained constructor pattern subsumption check of the form ; this can be shown to hold by matching and checking whether . Since
matching is decidable, the only undecidable check is the implication’s validity. Our tool employs multiple heuristics to check whether
. Given a goal , there are two final operations needed: (i) checking whether the proof failed, i.e., whether but not , (ii) as an optimization, discarding a goal where ’s constraint is unsatisfiable. These two checks are also undecidable in general, so we rely on besteffort heuristics. Interestingly, thanks to their use of the symbolic techniques for variant unification and satisfiability [variantJLAP, varsatscp, skeirikmeseguervarsatJLAMP], and for ordersorted congruence closure module axioms [DBLP:conf/fossacs/Meseguer16] mentioned in the Introduction, these heuristics were sufficient to complete all reachability logic proofs of the IBOS properties without relying on an external prover.Proving Inductive Invariants [DBLP:journals/fuin/SkeirikSM20, GRTcohcomplsymbmethTR]. For a transition system and a subset of initial states, a subset is called an invariant for from iff for each and , implies , where denotes the reflexivetransitive closure of . A subset is called stable in iff for each and , implies . An invariant for from is called inductive iff is stable. We instantiate this generic framework to prove invariants over a topmost rewrite theory with convergent and sufficiently complete with respect to and consider the transition system induced by over sort , i.e., .
To prove an invariant from over , we use a simple theory transformation mapping topmost theory to a theory having a fresh operator and a rule for each constructor of sort . Then, by Corollary 1 in [DBLP:conf/lopstr/SkeirikSM17], to prove is an invariant from over we prove and that the reachability formula holds over , where: (i) is a renaming of with and (ii) if then . If is inductive and , the proof of proceeds as follows:

The initial sequent is .

Apply the Step rule; based on which rule was used, obtain:

if is stop, ;

otherwise, .


For case (2a), apply Subsumption. For case (2b), apply zero or more derived rules to obtain sequents of the form: .

Since is assumed inductive, we have . Thus, apply Axiom to derive .

Finally, apply Subsumption.
Since all the IBOS security properties are invariants, all our proofs follow steps (1)–(5) above.
4 IBOS and its Security Properties
One important security principle adopted by all modern browsers is the sameorigin policy (SOP): it isolates web apps from different origins, where an origin is represented as a tuple of a protocol, a domain name, and a port number. For example, if a user loads a web page from origin (https,mybank.com,80) in one tab and in a separate tab loads a web page from origin (https,mybnk.com,80), i.e., a spoofed domain that omits the ‘a’ in ‘mybank,’ any code originating from the spoofed domain in the latter tab will not be able to interact with the former tab. SOP also ensures that asynchronous JavaScript and XML (AJAX) network requests from a web app are routed to its origin. Unfortunately, browser vendors often fail to correctly implement the SOP policy [Chen07, Schwenk2017].
The Illinois Browser Operating System (IBOS) is an operating system and web browser that was designed and modeled in Maude with security and compatibility as primary goals [DBLP:conf/osdi/TangMK10, tangthesis, DBLP:conf/facs2/SasseKMT12]. Unlike commodity browsers, where security checks are implemented across millions of lines of code, in IBOS a small trusted computing base of only 42K code lines is established in the kernel through which all network interaction is filtered. What this means in practice is that, even if highly complex HTML rendering or JavaScript interpretation code is compromised, the browser still cannot violate SOP (and several other security properties besides). The threat model considered here allows for much of the browser code itself to be compromised while still upholding the security invariants we describe below.
In the following subsections we survey the IBOS browser and SOP, how the IBOS browser can be formally specified as a rewriting logic theory, and how the SOP and other IBOS security properties can be formally specified as invariants.
4.1 IBOS System Specification
IBOS System Design. The Illinois Browser Operating System is an operating system and web browser designed to be highly secure as a browser while maintaining compatibility with modern web apps. It was built on top of the microkernel L4Ka::Pistachio [klein2004towards, kolanski2006formalising], which embraces the principles of least privilege and privilege separation by separating operating subsystems into separate daemons that communicate through the kernel via checked interprocess communication (IPC). IBOS directly piggybacks on top of this microkernel design by implementing various browser abstractions, such as the browser chrome and network connections, as separate components that communicate using L4ka kernel message passing infrastructure. Figure 1 gives an overview of the IBOS architecture; as an explanatory aid we highlight a few key objects:

Kernel. The IBOS kernel is built on top of the L4Ka::Pistachio microkernel which, as noted previously, can check IPC messages against security policies.

Network Process. A network process is responsible for managing a network connection (e.g., HTTP connections) to a specific origin. It understands how to encode and decode TCP datagrams and Ethernet frames and can send and receive frames from the network interface card (NIC).

Web Application. A web application represents a specific instance of a web page loaded in a particular browser tab (e.g., when a link is clicked or a URL is entered into the address bar). Web applications know how to render HTML documents. As per SOP, each web page is labeled by its origin.

Browser UI. The browser user inferface (UI) minimally includes the address bar and the mouse pointer and extends to any input mechanism.

Display. The display represents the rendered web app shown to the user; it is blank when no web app has loaded. For security, it cannot modify the UI.
IBOS System Specification in Maude. We present an overview of the IBOS formal executable specification as a Maude rewrite theory, which closely follows previous work [DBLP:conf/facs2/SasseKMT12, sassethesis, rochathesis]; a more detailed explanation can be found in Appendix 0.B. We model IBOS as an objectbased rewrite theory (see Section 2). We use italics to write Maude rewrite rules and CamelCase for variable or sort names. Some objects of interest include the singleton objects kernel, ui, and display (in classes Kernel, UI, and Display, respectively). We also have nonsingleton classes WebApp and NetProc representing web apps and network processes in IBOS, respectively.
As an example, let us consider the specification of the changedisplay rewrite rule shown in Figure 2.
if 
This rule involves the display object and the WebApp designated as the display’s activeTab. In our model, the rendered attribute of a web app represents its current rendering of the HTML document located at its origin. When the web app is first created, its rendered attribute has the value aboutblank, i.e., nothing has yet been rendered. Thus, this rule essentially states that, at any time, the displayed content can be replaced by currently rendered HTML document of the active tab, only if it is different from the currently displayed content.
Our IBOS browser specification contains 23 rewrite rules and is about 850 lines of Maude code; it is available at https://github.com/sskeirik/iboscasestudy.
4.2 Specification of the IBOS Security Properties
We first describe at a high level the security properties that we will formally specify and verify. The key property that we verify is the sameorigin policy (SOP), but we also specify and verify the address bar correctness (ABC) property. Our discussion follows that of [DBLP:conf/facs2/SasseKMT12, sassethesis], based on invariants :

Network requests from web page instances must be handled by the proper network process.

Ethernet frames from the network interface card (NIC) must be routed to the proper network process.

Ethernet frames from network processes to the NIC must have an IP address and TCP port that matches the origin of the network process.

Data from network processes to web page instances must be from a valid origin.

Network processes for different web page instances must remain isolated.

The browser chrome and web page content displays are isolated.

Only the current tab can access the screen, mouse, and keyboard.

All components can only perform their designated functions.

The URL of the active tab is displayed to the user.

The displayed web page content is from the URL shown in the address bar.

All configurations are wellformed, i.e., nonduplication of Oids and Atts.
We define sameorigin policy as ; addressbar correctness is specified as . Note that . Since , , and follow directly from the model design, it is sufficient to prove for . Invariant is new to our current formalization, but is implicitly used in prior work; it forbids absurd configurations, e.g., having two kernels or a WebApp that has two URLs (see Section 2). Due to its fundamental relation to how objectbased rewrite theories are defined, we need in the proof of all other invariants. As an example of how these invariant properties can be formalized in our model as constrained pattern predicates, we show how the address bar correctness invariant can be specified in our system below:
(1) 
where , i.e., the display is either blank or its contents’ origin matches the address bar. Note that, for simplicity, in our model, we identify displayed content with its origin URL. As a second example, consider how to formalize invariant :
(2) 
i.e., the address bar must match the URL of the active tab, unless the address shown is aboutblank, i.e., nothing is shown. Finally, has a trivial encoding: , where is the wellformedness predicate. Our specification has 200 lines of Maude code to specify the pattern predicates used in our invariants and another 900 lines of code specifying all of the auxiliary functions and predicates. As stated in the Introduction, we additionally must prove that: (a) the IBOS system specification extended by our security property specification is suitable for symbolic reachability analysis; and (b) our ABC and SOP invariants are at least as strong as the corresponding invariants in prior work [DBLP:conf/facs2/SasseKMT12, sassethesis] and . Proof obligation (a) can be met by using techniques for proving ground convergence and sufficient completeness of conditional equational theories, while proof obligation (b) can be reduced to proving associated implications, e.g., . We have carried out full proofs of (a) and (b); due to space limitations, the full details are available at [skeirikthesis].
5 Proof of IBOS Security Properties
In this section, due to space limitations, we give a highlevel overview of our proof methodology for verifying the SOP and ABC properties for IBOS, and show a subproof used in deductively verifying ABC. Each proof script has roughly 200 lines of code and another 20 to specify the reachability logic sequent being proved.
Modular Proof Methodology. In this subsection we survey our modular proof methodology for proving invariants using reachability logic and comment on how we exploit modularity in three key ways, i.e., we show how we efficiently structured and carried out our proofs by decomposing them into composable, independent, and reusable pieces.
Most of the IBOS proof effort was spent strengthening an invariant into an inductive invariant , where is either SOP or ABC. Typically, is obtained by iteratively applying the proof strategy given in Section 2. In each round, assume candidate is inductive and attempt to complete the proof. If, after applying the Step rule (and possibly some derived rules), an application of Axiom is impossible, examine the proof of failed pattern subsumption in the sidecondition of Axiom. If pattern formula (possibly using new functions and predicates defined in theory ) can be found that might enable the subsumption proof to succeed, try again with candidate . In parallel, our system specification is enriched by extending the underlying convergent equational theory to to obtain the enriched rewrite theory .
The first kind of modularity we exploit is rule modularity. Recall that any reachability logic proof begins with an application of the Step rule. Since Step must consider the result of symbolically rewriting the initial sequent with all possible rewrite rules, we can equivalently construct our proof on a “rulebyrule” basis, i.e., if , we can consider separate reachability proofs using respective theories for . Thus, we can focus on strengthening invariant for each rule separately.
Another kind of modularity that we can exploit is subclass modularity. Because we are reasoning in an objectbased rewrite theory, each rule mentions one or more objects in one or more classes, and describes how they evolve. Recall from Sect. 2 that subclasses must contain all of the attributes of their superclass, but may define additional attributes and have additional rewrite rules which affect them. The upshot of all this is that if we refine our specification by instantiating objects in one class into some subclass, any invariants proved for the original rules immediately hold for the same rules in the refined specification. Because of rule modularity, we need only prove our invariants hold for the newly defined rules. Even among newly defined rules, all noninterfering rules trivially satisfy any already proved invariants, where noninterfering rules do not directly or indirectly influence the state of previously defined attributes.
Lastly, we exploit what we call structural modularity. Since our logic is constructorbased and we assume that
matching is decidable, by pattern matching we can easily specify a set
of sequents to which we can apply the same combination of derived proof rules. This is based on the intuition that syntactically similar goals typically can be proved in a similar way. More concretely, given a set of reachability formulas and pattern , we can define the subset of formulas . Although the simplified example below does not illustrate structural modularity, we have heavily exploited this principle in our formal verification of IBOS.Address Bar Correctness Proof Example. Here we show a snippet of the ABC invariant verification, namely, we prove that the invariant holds for the changedisplay rule by exploiting rule modularity as noted above. As mentioned in our description of invariant , wellformedness is required for all invariants. Therefore, we begin with as our candidate inductive invariant, which, as mentioned in Sect. 2, normalizes by disjoint unification to the invariant:
where for brevity expands to the entire term of sort Conf wrapped inside operator , i.e., the entire configuration is wellformed. Recall the definition of the changedisplay rule in Section 4.1. We can see that our invariant only mentions the kernel and display processes, whereas in rule changedisplay the value of displayContent depends on the rendered attribute of a WebApp, i.e., the one selected as the activeTab. Clearly, our invariant seems too weak. How can we strengthen it? The reader may recall , which states “the URL of the active tab is displayed to the user.” Thus, by further disjoint unification, the strengthened invariant normalizes to:
This new invariant is closer to what we need, since the pattern now mentions the particular web app we want. Unfortunately, since our invariant still knows nothing about the rendered attribute, at least one further strengthening is needed.
At this point, we can enrich our theory with a new predicate stating that the rendered and URL attributes of any WebApp always agree^{1}^{1}1Note that, in a very real sense, this requirement is at the heart of the SOP, since it means that any WebApp has indeed obtained content from its claimed origin.. Let us declare it as . We can define it inductively over configurations by:
()  
()  
() 
where ambiguously denotes a predicate that holds iff an Oid refers to a web app. Intuitively, it says that whatever a WebApp has rendered is either blank or has been loaded from its URL. The strengthened invariant becomes:
where, as before, the represents the entire term of sort Conf enclosed in . Now, all of the required relationships between variables in the rewrite rule seem to be accounted for. Uneventfully, with the strengthened invariant , the subproof for the changedisplay rule now succeeds.
6 Related Work and Conclusions
Related Work on IBOS Verification. In this paper, we have presented the first full deductive verification of SOP and ABC for IBOS. Note that in [DBLP:conf/facs2/SasseKMT12, sassethesis], SOP and ABC were also verified. Their approach consisted of a handwritten proof that any counterexample must appear on some trace of length plus bounded model checking showing that such counterexamples are unreachable on all traces of length . In [rochathesis], an attempt was made to deductively verify these same invariants via the Maude invariant analyzer. Though a few basic invariants were proved, due to thousands of generated proof obligations, none of the properties listed in Sect. 4.2 were verified. Compared to previous work, this paper presents the first full deductive verification of IBOS security properties.
Related Work on Browser Security. In terms of computer technology, the sameorigin policy is quite old: it was first referenced in Netscape Navigator 2 released in 1996 [JSGuideV12]. As [Schwenk2017] points out, different browser vendors have different notions of SOP. Here, we situate IBOS and our work into this larger context. Many papers have been written on policies for enforcing SOP with regards to frames [barth2009securing], thirdparty scripts [jackson2008beware, karlof2007dynamic], cached content [jackson2006protecting], CSS [Huang:2010:PBC:1866307.1866376], and mobile OSes [Wang:2013:UOC:2508859.2516727]. Typically, these discussions assume that browser code is working as intended and then show existing policies are insufficient. Instead, IBOS attacks the problem taking a different tack: even if the browser itself is compromised, can SOP still be ensured? What the IBOS verification demonstrates is that —by using a minimal trusted computing base in the kernel, implementing separate web frames as separate processes, and requiring all IPC to be kernelchecked— one can in fact enforce the standard SOP notions, even if the complex browser code for rendering HTML or executing JavaScript is compromised. Although our model does not treat JavaScript, HTML, or cookies, explicitly, since it models system calls which are used for process creation, network access, and interprocess communication, code execution and resource references can be abstracted away into the communication primitives they ultimately cause to be invoked, allowing us to perform strong verification in a highlevel fashion. [bugliesi2017formal] surveys many promising lines of research in the formal methods web security landscape. Prior work on formal and declarative models of web browsers includes [bauer2015run] as well as the executable models [bohannon2010featherweight, bohannon2012foundations]. Our work complements the Quark browser design and implementation of [jang2012establishing]: Quark, like IBOS, has a small trusted kernel (specified in Coq). In addition to proving tab noninterference and address bar correctness theorems, the authors use Coq code extraction to produce a verified, functional browser. Unlike Quark, whose TCB includes the entire Linux kernel and Coq code extraction tools, the TCB of the IBOS browser consists of only 42K lines of C/C++ code.
Related Work on Reachability Logic. Our work on constructorbased reachability logic [DBLP:conf/lopstr/SkeirikSM17, DBLP:journals/fuin/SkeirikSM20] builds upon previous work on reachability logic [DBLP:conf/fm/RosuS12, DBLP:conf/oopsla/RosuS12, DBLP:conf/rta/StefanescuCMMSR14, DBLP:conf/oopsla/StefanescuPYLR16] as a languagegeneric approach to program verification, parametric on the operational semantics of a programming language. Our work extends in a nontrivial manner reachability logic from a programminglanguagegeneric logic of programs to a rewritetheorygeneric logic to reason about both distributed system designs and programs based on rewriting logic semantics. Our work in [DBLP:conf/lopstr/SkeirikSM17, DBLP:journals/fuin/SkeirikSM20] was also inspired by the work in [DBLP:conf/birthday/LucanuRAN15], which for the first time considered reachability logic for rewrite theories, but went beyond [DBLP:conf/birthday/LucanuRAN15] in several ways, including more expressive input theories and state predicates, and a simple inference system as opposed to an algorithm. Also related to our work in [DBLP:conf/lopstr/SkeirikSM17, DBLP:journals/fuin/SkeirikSM20], but focusing on coinductive reasoning, we have the recent work in [moorethesis, DBLP:journals/jsc/LucanuRA17, DBLP:conf/cade/CiobacaL18], of which, in spite of various substantial differences, the closest to our work regarding the models assumed, the kinds of reachability properties proved, and the state predicates and inference systems proposed is the work in [DBLP:conf/cade/CiobacaL18].
Conclusion and Future Work. We have presented a full deductive proof of the SOP and ABC properties of the IBOS browser design, as well as a prover and a modular reachability logic verification methodology making proofs scalable to substantial proof efforts like that of IBOS. Besides offering a case study that can help other distributed system verification efforts, this work should also be seen as a useful step towards incorporating the IBOS design ideas into future fully verified browsers. The web is alive and evolving; these evolution necessitates that formal approaches evolve as well. Looking towards the future of IBOS, two goals stand out: (i) extending the design of IBOS to handle some recent extensions of the SOP, e.g., crossorigin resource sharing (CORS) to analyze potential crosssite scripting (XSS) and crosssite request forgery attacks (XSRF) [gollmannsop2011], and to check for incompatible content security policies (CSP) [bielovacsp2017] in relation to SOP; by exploiting subclass and rule modularity, the verification of an IBOS extension with such new functionality could reuse most of the current IBOS proofs, since extra proofs would only be needed for the new, functionalityadding rules; and (ii) exploiting the intrinsic concurrency of Maude rewrite theories to transform them into correctbyconstruction, deployable Maudebased distributed system implementations, closing the gap between verified designs and correct implementations. Our work on IBOS takes one more step towards demonstrating that a formally secure web is possible in a connected world where security is needed more than ever before.
References
Appendix 0.A Reachability Logic Derived Proof Rules
For completeness, we document the three derived rules in our proof system in Table 2, provide some intuitive explanations of how they are used, and finally make a few general comments about how they are automated.
Assumption: is suff. comp. w.r.t.
Name  Rule  Condition 

Case  
Split  
Subst. 
.
is decidable.
In some sense, the Case and Split rules are performing the exact same operation. In the former, we are considering how to decompose a variable into multiple patterns which entirely cover the sort of the given variable; in the later, we are considering how we can decompose the true formula into a set of quantifierfree formulas whose disjunction is equivalent to . In either case, what we want is to make use of the extra information available after case analysis or formula splitting to help us discharge pattern subsumption proofs in the sidecondition of Axiom. These rules are both essential for our proofs of both SOP and ABC, since they allow us to infer additional information in a sound way that is implied by application of the system rewrite rules but not directly stated. The Substitution rule has a slightly different flavor from Case or Split; essentially, it encodes a commonly applicable sequent simplification technique when a fragment of the sequent constraint is a unifiable conjunction of equalities. Its usefulness primarily comes from the fact that such unifications often fail, which can lead to a huge reduction in the number of goals to be proved.
As for automation, these rules present no special difficulties. Substitution is implementable directly by Maude’s builtin unification modulo axioms and variant unification algorithms. The Case and Split rules are also easy to apply. Regarding the checking of their side conditions, checking in Case that is a cover set for sort is easy to automate by tree automata modulo axioms techniques supported by Maude’s Sufficient Completeness Checker [hendrixmeseguerohsakiijcar06, hendrixthesis]. In the case of Split, although proving that an arbitrary disjunction of formulas is inductively equivalent to in the initial algebra is in general undecidable, in practice is not arbitrary at all, since typically has the form , where is a Boolean expression, or the form , for a QFformula; so such checks are trivial in practice.
Appendix 0.B IBOS System Specification in Maude
To ground our discussion we recap here some details of the IBOS specification. The Maude rewrite theory specifying the IBOS system design in total consists of approximately 850 lines of code and defines 23 rewrite rules. The main pattern predicate defining the SOP is about 180 lines of code while the main pattern predicate defining ABC is about 20 lines of code. Their supporting predicate definitions used to define the inductive invariant is about 900 lines of code. The reachability formulas specifying the inductive invariants for the IBOS SOP and ABC security properties in our Maude reachability logic tool notation are roughly 20 lines each. The proof scripts which verify that the respective inductive invariants hold for each proof rule excluding comments and boilerplate text are about 200 lines each. In total, there are approximately 2500 lines of code.
As a further aid to the reader and a complement to the graphical overview of IBOS in Figure 1, we rewrite this graphical figure using our formal specification. Said another way, we provide in Figure 3 a representative state (e.g., a ground term) of the transition system where is the Maude rewrite theory specifying IBOS. To improve readability, we write each object attribute on a separate line.
Let us make a few highlevel remarks about the figure. In our specification, urls are encoded as numbers wrapped by constructor . In IBOS, to enforce SOP as well as other security policies, both browser frames and network connections must be tracked. Each browser frame is represented by an object of class WebApp, while each network connection is represented by an object of class NetProc. The kernel manages process state by internal metadata tables webAppInfo where each web app is tagged by its origin and netProcInfo where each network connection is tagged by its origin web app and destination server. When a new web app is created, the kernel automatically creates a corresponding network process between the webapp and its origin server. Since the kernel is responsible for creating network connections, it records the next fresh network process identifier in nextNetProc.
The kernel’s secPolicy attribute stores its security policy. Each policy consists of a sender, a receiver, and a message type. Any message not explicitly allowed by the policy is dropped. In the policy, the special Oids network and webapp represent a policy allowing any network process or webapp to send a particular kind of message to its corresponding webapp or network process, respectively. In the figure, the kernel is preparing to forward a message from to its corresponding network process asking to fetch an item from the web app’s origin .
Aside from the kernel, the system has a few other distinguished objects. The display object tracks the content currently shown on the screen in displayContent; to do that, it should know which web app is the activeTab. The ui (user interface) contains the list of commands given by the user during some usage session in its toKernel attribute. The webappmgr (web app manager) is responsible for spawning new web apps; in our model, it just records the next fresh web app identifier in attribute nextWebApp. Finally, the nic (network interface card) has two attributes for ingoing and outgoing data. In our model, we identify urls and their loaded content. To model network latency, outgoing messages in nicout are queued up in nicin in a random order.
Of course, we also have objects representing web apps and network connections. In the figure, ’s rendered content is blank. However, it is currently loading its content from its origin url(15); its request to fetch data from its corresponding network process is currently being handled by the kernel. Currently, its toKernel and fromKernel IPC message queues are blank because it is not performing any other communication at this time. There is also a corresponding network process network(0); it has two directmemory access (DMA) buffers memin and memout that are used as I/O channels between itself and the network card driver. Like web apps, network processes also have two IPC message queues. Finally, a network process also stores which web app its received data should be sent back to.
Comments
There are no comments yet.