On 03/20/2013 07:14 PM, Johan Tibell wrote:> Just as
> sandboxing is a better way to run untrusted software than trying to plug
> every whole in your code/RTS,

(Citation needed). There have been lots of exploits of VMs and
sandboxes. This is also irrelevant to DoS prevention, AFAICT.

> generic anti-DoS techniques are usually
> better than trying to figure out every possible way someone can DoS you.

(Citation needed.)

There's no excuse for not preventing obvious an relatively easily
preventable problems. Security in Depth and all that.

My only citation is that this is how we do things, but I think you can make a theoretical argument for it as well. This is what I tried to do with the sandboxing analogy.

The reason that sandboxing works well is that it's a whitelist approach (instead of a blacklist approach). I should note that when I talk about sandboxing I don't really mean a VM, but rather a chroot/process isolation approach, like AppEngine. If you only allow the e.g. AppEngine user code to modify the system via a few select RPCs and then block all file system access by default, you can avoid having to audit every single API that the platform offers.

Now, for DoS protection we can do something similar. We have a detector for bad behavior (e.g. long running connections that time out, etc) and a generic mechanism for rejecting such users (IP blocking). That way we don't have to inspect everything the app itself does that could open it up for a DoS attack.

You're of course right that current Haskell frameworks don't do this. There hasn't really been a need yet.

-- Johan