mediagoblin-userops
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Userops] How Sandstorm enables userops (rather than "dev"eleoper op


From: Shawn Landden
Subject: Re: [Userops] How Sandstorm enables userops (rather than "dev"eleoper ops) (part 1)
Date: Tue, 7 Apr 2015 14:48:46 -0700

On Mon, Apr 6, 2015 at 12:36 PM, Asheesh Laroia <address@hidden> wrote:
> Hi Shawn!
>
> On Sun, Apr 5, 2015 at 11:53 AM, Shawn Landden <address@hidden>
> wrote:
>>
>> On Fri, Apr 3, 2015 at 10:21 AM, Asheesh Laroia <address@hidden>
>> wrote:
>> > Hey nice userops people,
>>
>> I don't understand why you have to use "legacy-bridge" with
>> cap-n-proto instead of just passing in a bound file descriptor. (which
>> the app will call accept() on)
>
>
> Great question.
>
> One goal is to enable apps to speak just a subset of HTTP; we're concerned
> about HTTP protocol parsing differences leading to security issues. HTTP
> request splitting is a pretty common problem in web apps; see also
> https://access.redhat.com/security/cve/CVE-2015-0881 for a recent
> vulnerability along these lines. Related is that we want to whitelist
> specific HTTP methods and headers to pass into apps running in the sandbox.

Wow! add another to the list...
https://www.varnish-cache.org/docs/trunk/phk/http20.html

>
> Given that, we'll need to decode HTTP somewhere. We do that outside the
> sandbox, and we pass the parsed data into the sandbox where the app runs. If
> the app wants, it can speak the *parsed HTTP* protocol instead of a text
> protocol.
>
> If the app wants to speak text-based HTTP, then we provide
> sandstorm-http-bridge for that. (Nearly every app wants to speak text HTTP,
> I admit, but some new apps are being written with the Sandstorm *parsed
> HTTP* protocol instead. For Python, one could imagine a WSGI wrapper that
> skips text HTTP, for example.)
>
> Similarly, on the way out of the sandbox, we want to protect users from apps
> that might do insane things in HTTP responses. So we pass a parsed HTTP
> protocol out of the sandbox, which means something _in_ the Sandbox has to
> convert text-HTTP from the app into a checkable subset on the way out.
> sandstorm-http-bridge provides that, too.
>
> We also are using the sandstorm-http-bridge for other, non-HTTP things that
> the app is authorized to do, since it's a convenient place to add those
> protocols. One example is outbound SMTP; rather than providing apps raw
> access to port 25, we give them a Cap'n Proto protocol instance to speak
> HTTP with.
>
> https://github.com/sandstorm-io/sandstorm/blob/master/src/sandstorm/hack-session.capnp
> (which is linked-to from
> https://github.com/sandstorm-io/sandstorm/wiki/Sandstorm-App-Developer-Handbook
> ) provides some more info.
>
> I hope this is helpful! Let me know if you have more questions.
>
> -- Asheesh.



-- 
Liberty equality fraternity or death,

Shawn Landden
ChurchOfGit.com


reply via email to

[Prev in Thread] Current Thread [Next in Thread]