Proposal: Add the unordered-containers package and the hashable package to the Haskell Platform

Johan Tibell johan.tibell at gmail.com
Wed Mar 20 19:49:16 CET 2013


On Wed, Mar 20, 2013 at 11:40 AM, Bardur Arantsson <spam at scientician.net>wrote:

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20130320/7f093d9e/attachment.htm>


More information about the Libraries mailing list