Sandcrust

Lamowski, Benjamin; Weinhold, Carsten; Lackorzyński, Adam; Härtig, Hermann

doi:10.1145/3144555.3144562

Cited by 23 publications

(8 citation statements)

References 13 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The main reason for including concurrency in λ sandbox is to more faithfully model practical isolation techniques, which typically operate in a concurrent setting [Mozilla 2019;Lamowski et al 2017;Google 2019;Litton et al 2016]. Consequently, as we will see in Section 6, we will need to verify that wrappers handle concurrent accesses correctly.…”

Section: Key Ideasmentioning

confidence: 99%

“…To switch the privilege level, λ sandbox provides a call gate mechanism, often employed by realworld sandboxing techniques [Lamowski et al 2017;Google 2019;Litton et al 2016;Vahldiek-Oberwagner et al 2019]. Namely, a switch of the privilege is combined with a call to a function preregistered by the code on the other side of the sandbox.…”

Section: Key Ideasmentioning

confidence: 99%

“…A location that points to the high heap (i.e., whose privilege bit is High) is called a high location, and similarly a location with p = Low is called a low location. We chose to model coarse-grained memory isolation since it is used in most real-world sandboxing techniques [Litton et al 2016;Vahldiek-Oberwagner et al 2019;Lamowski et al 2017;Google 2019]. The parameter p in alloc p specifies in which heap the allocation lands.…”

Section: Key Ideasmentioning

confidence: 99%

“…They are primarily used to reduce development effort and improve software maintainability, but in some applications, notably Mozilla's Firefox [Mozilla 2019], wrappers are also used to improve security. Wrappers are often combined with sandboxing in practice, e.g., in Lamowski et al [2017], but they are typically limited to marshalling and unmarshalling records of first-order values. In contrast, our wrappers cover a rich type system with affine and ownership types, and we show how these types can be wrapped and unwrapped securely.…”

Section: Introductionmentioning

confidence: 99%

“…Specifically, if we verify a safety property of trusted code assuming that all its interactions with the untrusted code are at a type we call anyÐwhich includes all values of the languageÐthen that safety property also holds when the trusted code runs co-linked with any untrusted code.As an add-on, we extend our formalization to another low-level engineering technique that is commonly used in conjunction with sandboxing. This technique, often called łwrappingž or łmarshallingž [Mozilla 2019;Lamowski et al 2017;Google 2019;Swasey et al 2017], dynamically converts values between types that two different components of an application use internally. In the context of sandboxing, where we assume nothing of the untrusted code, wrapping can be used to convert between types that the trusted code understands and the type any.…”

mentioning

confidence: 99%

See 4 more Smart Citations

The high-level benefits of low-level sandboxing

Sammler

Garg

Dreyer

et al. 2019

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

Sandboxing is a common technique that allows low-level, untrusted components to safely interact with trusted code. However, previous work has only investigated the low-level memory isolation guarantees of sandboxing, leaving open the question of the end-to-end guarantees that sandboxing affords programmers. In this paper, we fill this gap by showing that sandboxing enables reasoning about the known concept of robust safety, i.e., safety of the trusted code even in the presence of arbitrary untrusted code. To do this, we first present an idealized operational semantics for a language that combines trusted code with untrusted code. Sandboxing is built into our semantics. Then, we prove that safety properties of the trusted code (as enforced through a rich type system) are upheld in the presence of arbitrary untrusted code, so long as all interactions with untrusted code occur at the łanyž type (a type inhabited by all values). Finally, to alleviate the burden of having to interact with untrusted code at only the łanyž type, we formalize and prove safe several wrappers, which automatically convert values between the łanyž type and much richer types. All our results are mechanized in the Coq proof assistant. One common engineering technique for ensuring secure interoperation between trusted and untrusted code is to physically sandbox the untrusted parts of an application at coarse granularity using hardware, kernel, or library support for isolation. Memory is partitioned into low and high compartments, and the hardware and kernel enforce that untrusted codeÐsandboxed in the low compartmentÐcannot directly access the memory in the high compartment (where trusted code operates) even if it can guess private memory addresses of the trusted code [Koning et al. 2017]. Additionally, untrusted code cannot directly access system calls. Examples of such techniques are software fault isolation by rewriting untrusted code [Yee et al. 2009], in-user-space sandboxing of untrusted libraries [Mozilla 2019; Lamowski et al. 2017; Google 2019; Vahldiek-Oberwagner et al. 2019], use of multiple kernel-backed address spaces within an application [Litton et al. 2016], and the use of modern features of CPUs like secure enclaves [McKeen et al. 2013; ARM Limited 2009].Although sandboxing is widely used, and prior work has shown formally that specific sandboxing techniques attain intrinsic properties like memory isolation, to the best of our knowledge there is no clear understanding of what end-to-end reasoning sandboxing affords programmers. Our goal in this paper is precisely to fill this gap: we show that sandboxing allows programmers to reason about the robust safety of trusted code. As explained above, robust safety is a well-studied concept, which means that the trusted code's safety properties hold even when co-executing with arbitrary untrusted code. In verification terms, sandboxing allows reasoning about the safety properties of trusted code without having to consider the behavior of untrusted code during verification.To formalize th...

show abstract

Section: Key Ideasmentioning

confidence: 99%

Section: Key Ideasmentioning

confidence: 99%