SWS   Info

MPI Audience

English

60 Minutes

Saarbrücken

Function-as-a-Service (FaaS) is an emerging high-level abstraction for event-driven cloud applications. The
FaaS abstraction allows tenants to state their application logic in the form of stateless event-triggered functions
without the need to provision or manage the underlying infrastructure that runs and scales their application. One
of the core responsibilities of a FaaS provider is ensuring the confidentiality of its tenants’ data. To that end, FaaS
providers isolate functions from one another, thus preventing a malicious or compromised function from affecting
the confidentiality of other functions. However, due to performance considerations, the same degree of isolation
does not apply to sequential requests reaching the same function. This compromise can lead to severe security
implications, since bugs in a function implementation — or a third-party library/runtime it depends on — may cause
a leak of information from one activation of the function to a subsequent one.

Conceptually, sequential request isolation can be achieved by maintaining two invariants: a confidentiality one,
where confidential data (such as end-client inputs, or credentials) should not flow from one function activation to
the subsequent one, and a correctness one, where non-confidential but critical state (such as the internal state of a
Pseudo Random Number Generator (PRNG)) should be maintained across sequential activations of the function
to allow the intended functionality. We define the sequential request isolation problem in terms of the data flows
that exist within and across invocations. As such, both invariants can be cast as data flow problems with dynamic
policy updates at the request boundary. To this end, we propose two complementary approaches for achieving
sequential request isolation by enforcing policies on data flows that cross the request boundary.

First, we propose Groundhog, a system that enforces the confidentiality invariant by implementing a simple
fixed policy: any changes to a function’s internal state during the handling of a request are rolled back. By doing
this, Groundhog confines all data flows to a single request context, thereby enforcing the confidentiality invariant “by design". While enforcing the confidentiality invariant is sufficient for many FaaS applications where the statelessness of functions and the ephemerality of execution environments are the norm, developers have no access to tools that
help them verify that the correctness invariant is also met.

Next, we propose CtxTainter, an extension to standard dynamic data flow analysis (DDFA) techniques that
aid developers in performing context-aware analyses. Unlike standard DDFA which can only track data flows,
CtxTainter is additionally able to simultaneously reason about request-context boundaries and can thus detect both
confidentiality- and correctness-critical data flows that cross a request-context boundary. While this approach can
only provide best-effort confidentiality (when used standalone), it can also complement Groundhog by providing
best-efforts correctness-invariant violation detection.

Groundhog is a black-box solution that is transparent to both the developer and the provider; it is programming-
language agnostic, and does not require any changes to existing code of functions, libraries, language runtimes, 

or OS kernels but requires provider collaboration to enable it. Groundhog incurs moderate-to-low overhead relative
to an insecure baseline. In contrast, CtxTainter is an easy-to-configure development-phase tool that does not
require any support or modifications from the platform provider but requires active developer participation to
review and fix detected violations.

--email hidden

Zoom

923 6785 8852

passcode not visible

logged in users only