(Adding Louis to cc per his request)
Quoting Kenton Varda (2021-11-23 14:50:20)
> On Tue, Nov 23, 2021 at 12:41 PM Ian Denhardt <i...@zenhack.net
> Wouldn't releasing it on return allow the caller to cause runaway
> usage by just never sending the finish? the return entry needs to be
> around in case calls are pipelined on it, and itself might take up
> space (arguably it should count against the limit too...).
> In all honesty, this isn't a very good defense against resource
> exhaustion attacks either way. The problem that motivated it was
> actually badly-written apps that would stream a whole large HTTP
> response body without paying attention� to backpressure.
What are apps *supposed* to do here? It isn't clear to me where else the
backpressure is supposed to come from?
Most apps are using sandstorm-http-bridge anyway, so they're just acting
like normal http servers -- which generally write out data to the
response stream as fast as the socket will take it. Skimming
sendRequest() in the bridge's source, it looks like it just copies that
data directly into the response stream. So I am confused as to what a
"well written" app would do?
> Technically the callee doesn't need to keep the whole response struct
> in memory, only any returned capabilities and their paths. The current
> implementation does keep the whole struct� though.
> My general opinion about resource exhaustion is that it's not so much a
> security issue as an abuse issue. These attacks create a temporary
> nuisance� / disruption, but no permanent damage. It's probably
> impossible to anticipate every attack. But, since the attacks don't
> actually get anything for the attacker, they are much more rare than
> you might think, and it's usually fine to respond reactively by
> revoking capabilities, banning users, blocking IPs, etc. If the problem
> recurs then you start investing new safeguards against the specific
I suppose that's a reasonable perspective; you're right that it's a
different beast (Mark Miller wrote
really useful for thinking about this stuff. In his terminology we are
talking about availibility rather than integrity).
Every approach I've been able to think of for dealing with availability
attacks gracefully in the capnp implementation itself does seem very
fragile. Perhaps we could treat the flow limit as a soft limit, not
bound the space taken up by returns and table entries, but track it,
and provide a way to notify the user if it goes past a harder limit,
at which point they can drop the connection if they want. If we were
doing this at the process level I'd be inclined to just lean on the
kernel's resource management, but I'd like to a least find a way to
confine these issues to a single connection. Anyway, thanks for your