kentonv changed the topic of #sandstorm to: Welcome to #sandstorm: home of all things sandstorm.io. Say hi! | Have a question but no one is here? Try asking in the discussion group: https://groups.google.com/group/sandstorm-dev
frigginglorious has quit [Ping timeout: 260 seconds]
frigginglorious has joined #sandstorm
frigginglorious has quit [Ping timeout: 240 seconds]
isd has quit [Ping timeout: 246 seconds]
enick_820 has quit [Ping timeout: 246 seconds]
abliss1 has quit [Remote host closed the connection]
ill_logic has quit [Remote host closed the connection]
JacobWeisz[m] has quit [Read error: Connection reset by peer]
isd has joined #sandstorm
JacobWeisz[m] has joined #sandstorm
abliss1 has joined #sandstorm
Guest81835 has joined #sandstorm
nicoo has quit [Remote host closed the connection]
nicoo has joined #sandstorm
abliss has quit [Ping timeout: 264 seconds]
CcxWrk has quit [Ping timeout: 256 seconds]
CcxWrk has joined #sandstorm
kentonv has quit [Ping timeout: 260 seconds]
nicoo has quit [Remote host closed the connection]
frigginglorious has quit [Remote host closed the connection]
frigginglorious has joined #sandstorm
frigginglorious1 has joined #sandstorm
frigginglorious has quit [Ping timeout: 256 seconds]
frigginglorious1 is now known as frigginglorious
frigginglorious has quit [Read error: Connection reset by peer]
frigginglorious has joined #sandstorm
<abliss>
So I'm trying out using the `/.sandstorm-token/` path instead of the Authorization header for accessing my matrix grain. It seems to work great, which is nice because some matrix clients already seem to allow the use of an extra path segment (whereas none of them support taking a webkeys from the server url and sticking it in the authorization header).
<isd>
cool.
<abliss>
However, I was kind of hoping that since sandstorm was taking its token out of the path segment, it would be able to pass on the original request's Authorization header into the app itself. That seems to not happen; I get no Auth header at all.
<abliss>
Might it be resonable to forward the Auth header when using the token in the path? or is there too much risk of someone accidentally using both headers, and leaking the app's auth token back to itself? (which I suppose is thought to be bad, though I don't understand why)
frigginglorious has quit [Quit: frigginglorious]
<isd>
Remind me why you need to inspect the auth header again?
<isd>
Maybe you could put a proxy in front of the matrix http endpoint that looks at the X-Sandstorm-* headers and maps those to auth headers which it passes on to matrix inside the grain?
<abliss>
incoming requests from outside sandstorm want to use the auth header (either for a client app, or for a federated server request).
<abliss>
Right now, since I'm using apache to proxy the short url to the long sandstorm url, i can add a mod_header rewrite to change Authorization to X-Original-Authorization, and then add another apache inside the grain to change it back before sending it to the app. but that's kind of a bummer.
frigginglorious has joined #sandstorm
<isd>
Authorization header in a database, and then injects that into the request before passing it on to the matrix server?
<isd>
I guess what I'm thinking is, for client->server, can we rig it up so that the client submit's Sandstorm's authorization header (generated via the usual offer iframe mechanism), Sandstorm then makes the request into the grain having stripped off the auth header but inserted user info via the bridge's X-Sandstorm-* headers, then we put some daemon in front of the matrix server that looks at those headers, finds a corresponding
frigginglorious has quit [Read error: Connection reset by peer]
<isd>
I'm less clear on how server->server works
frigginglorious has joined #sandstorm
<isd>
This is not far off from what powerbox-http-proxy does; it maintains a mapping in a db of domain -> capability for that domain
<abliss>
matrix clients want to use the auth given to them from the matrix server. injecting a custom auth token would be an invasive change to every client app.
<isd>
Ah, I see.
<isd>
I do think docs should more clearly articulate what the thread model is re: letting grains see their own auth tokens; other than a generic POLA thing I'm not sure I see a serious problem either.
<isd>
And it would definitely be useful in some circumstances.
<isd>
Maybe kentonv can weigh in on this.
<kentonv>
if a grain can see its own tokens than leaking a capability to itself is reduced to leaking bits
<isd>
Aha, that makes sense.
<kentonv>
granted, it's a fairly paranoid policy most of the time, but there are use cases where people might care about this.
<kentonv>
in an ideal world, secret bits would never be exchangeable for a capability in themselves. Everything would operate like CapTP / Cap'n Proto with the Four Tables.
<kentonv>
but in that case, I guess displaying a capability back to the user would be even more complicated.
<abliss>
isd: maybe you could expand on "leaking a capability to itself is reduced to leaking bits" if it makes sense to you? Because I don't get it.
<abliss>
Hm, my plan to smuggle the original Authorization header in another header seems not to work. Does sandstorm only forward headers on some explicit allowlist?
<isd>
abliss: web-session.capnp is your authoritative reference.
<kentonv>
so, some people want their Sandstorm gains to be unable to communicate with the outside world at all
<isd>
There's a prefix like x-sandstorm-app- or something you can use.
<kentonv>
but preventing low-bandwidth covert side channels is pretty much impossible
<kentonv>
if a grain can get a token that represents access to itself, then it can leak that token via a low-bandwdith side channel in order to create a high-bandwidth channel
<abliss>
isd: awesome, thanks, x-sandstorm-app- works
<isd>
Not 100% sure that's the correct prefix, but it's documented in the capnp file.
<kentonv>
moreover if a grain can get a token to itself that represents the authority of one particular user of the grain, and then can leak that to some other user or non-user, the recipient can impersonate the first user for the purpose of audit logs, etc.
<abliss>
presumably you mean audit logs not written by the grain itself, because then why bother, but instead audit logs written by some higher level like sandstorm itself?
frigginglorious1 has joined #sandstorm
frigginglorious has quit [Ping timeout: 256 seconds]
frigginglorious1 is now known as frigginglorious
frigginglorious has quit [Read error: Connection reset by peer]
frigginglorious has joined #sandstorm
<isd>
Hm, what does Sandstorm do if you supply both a bogus Authorization header and a _correct_ token in the path? I would expect the answer to be reject the request, but if it accepted it, you could do the proxy thing I described above and just rely on the fact that the Authorization header will be ignored...
<isd>
But, all of this is contingent on Sandstorm not working the way I expect...
* isd
looks at source
<isd>
Ok, yeah, it only falls back to the path if the Authorization header is _absent_
<isd>
...though I guess we could invert the logic, so it just checks the path first... shrug
<abliss1>
it seems to strip the authorization header.
<abliss1>
i would love if it could be inverted so that when the path is present, the authorization header gets passed along as-is. but this does seems likely to leak a token in a misconfigured client.
<isd>
record the token, and then when it gets a subsequent requests, fetches that token out of the db (based on X-Sandstorm-* headers passed by the bridge), and adds it back to the request before passing it on to the matrix server.
<abliss1>
that doesn't work for federation api calls, which never login.
<abliss1>
but it's fine. i have apache rewriting the header when it proxies, and then i hacked the python request object to restore the header.
<abliss1>
next i need to add in your proxy, which is gonna require routing requests to your websocket thingy
<isd>
Right, this only gets as far as client->server.
<abliss1>
and if i end up using apache or nginx for that (instead of trying to figure out how python's twisted framework can be forced to do it), i can also do the header restoration at that layer.
<abliss1>
it looks like matrix federation does a weird thing where the incoming request includes in its Authorization header a crypto signature, and then my server has to reach out to the originating server to fetch its public key, to verify that the request is really authorized by their backend. so i need the proxy before i can get any further.
<abliss1>
(it also means, kinda unfortunately, nobody will be able to contact you from server X unless you have first, while logged in, tried to contact someone at server X, so that the powerbox could pop up a domain authorization.)
<abliss1>
(i'm thinking someday, when the proxy wants to fire to a new domain due to a backend api request or scheduled event, it'll be able to store up the request for later, and pop up a notification, so you can be notified that someone is trying to reach you, and log in to authorized the back-connect. something similar will be useful for adding a new feed to ttrss through a mobile app. but that can be tabled for later.)
<isd>
Part of me thinks matrix is just an example of an app that just needs full network access (or arbitrary HTTP anyway) in order to work. I don't know if we can build a reasonable UX around it trying to stick to per-host approvals.
<JacobWeisz[m]>
Is there a way to move that sanely into a system grain type design then?
<JacobWeisz[m]>
Should Sandstorm servers support multiple Matrix servers, or should there be a system grain that provides a Matrix server for Matrix client apps on the user side to connect to?
<isd>
abliss: I'm staring at the draft you put together the other week, and while we talked about doing the outreach thing with matrix, I'm tempted to suggest instead we reach out chris lemmer webber to put our heads together on activitypub; they're one of the primary authors of the spec and are also pretty nuts about capabilities, so that seems like an easy way to start thinking about how to make stuff fit while hopefully having to
<isd>
do less convincing up front.
<JacobWeisz[m]>
I am not sure if there is a strong use case for "every user on the server provides their own Matrix server", and our currently incomplete email solution is similar: Sandstorm handles the mail server and users install mail client apps.
<isd>
I think you could sensibly have a system grain that can fulfill requests for matrix client connections or such.
<abliss1>
i can see a system/driver grain which exposes a capability like "given a matrix domain, fetch its public key". hard to imagine exfiltrating much data through that, so it could be permissionless, and might allow for any incoming federation request to be servicable without user interaction.
<isd>
Office hours tonight. I'll post a new page and we can talk more about this then; I've got to help with dinner in a few.
<JacobWeisz[m]>
Okay.
<JacobWeisz[m]>
I really think anything that needs outright network access should probably be imagined as a system grain with normal grains being clients.
<JacobWeisz[m]>
It also possibly gives us a way to ensure the outside facing protocol for federation talks standard ActivityPub, Matrix, whatever, but then we are free to set our own rules with how users then interact with our system grain on the other side.
Mitar has quit [Ping timeout: 260 seconds]
Mitar has joined #sandstorm
sam_w has quit [Ping timeout: 244 seconds]
sam_w has joined #sandstorm
frigginglorious1 has joined #sandstorm
frigginglorious has quit [Ping timeout: 256 seconds]
frigginglorious1 is now known as frigginglorious
<abliss1>
in the abstract, i like the sound of that. but it's very hard for me to think concretely about system/driver grains without a working example to examine.
griff_ has quit [Quit: griff_]
<JacobWeisz[m]>
I imagine basically a plugin system for a Sandstorm server. A system/driver grain would be like an addon for the core functionality of the server.
<JacobWeisz[m]>
And of course, the system grain is sandboxed. So it shouldn't increase the attack surface of the Sandstorm server as a whole.
<JacobWeisz[m]>
Sandstorm currently handles email (poorly) but email is a good example of something that could possibly be punted out to a system grain.
<JacobWeisz[m]>
The way Sandstorm handles inbound mail is that Sandstorm itself is the destination mail server, and then grains are basically mail clients that connect to it/receive mail from it.
<JacobWeisz[m]>
As opposed to each user having their own mail server grains.