[Haskell-cafe] ANN: jail-0.0.1 - Jailed IO monad

[John Van Enk]

Neat!

On Thu, Aug 27, 2009 at 10:09 AM, Sebastiaan Visser <sfvisser at cs.uu.nl>wrote:

> Hi all,
>
> I am very pleased to announce the first release of the jail[1,2] package. A
> jailed IO monad that can restrict filesystem access for your code. This
> package will soon be an integral part of the Salvia web server. (a new and
> improved Salvia will be released soon)
>
> Basic documentation of the jail package is included below.
>
> Any comments, suggestions, audits, etc. are welcome!
>
> Gr,
>
> --
> Sebastiaan Visser
>
> [1] Source repo: http://github.com/sebastiaanvisser/jail/
>
> [2] Hackage: http://hackage.haskell.org/package/jail
>
>
>
> --------
>
> Like all of us know, the IO monad from the System.IO module is a wild beast
> allowing all forms of insecure computations that can read, or even worse,
> alter the real world. Writing to sockets, deleting files or even launching
> missiles, its possibilities are endless. This library provides a special IO
> module that wraps all file and handle based IO operations from the System.IO
> module, but provides a possibility to run them in an restricted environment.
> When running a jailed IO computation a file path can be specified all IO
> operations will be checked against. Accessing files outside this directory
> is not allowed and results in a runtime error. Additionally, when running a
> jailed IO computation a whitelist of file handles can be specified that are
> accessible as well.
>
> For example, running some code with the permission to access all files
> within (and only within) my home directory and allowing to access the
> standard output and standard error can be enforced like this:
>
>  Jail.run (Just "/home/sebas") [stdout, stderr]
> yourUntrustworthyComputation
> Only allowing the code to access the standard input and nothing else can be
> enforced like this:
>
>  Jail.run Nothing [stdin] yourEvenMoreUntrustworthyComputation
> Because the jailed IO environment keeps track of all file handles and
> checks that are opened by its own operations, smuggling in evil file handles
> from the fierce and dangerous outside world will be punished by border
> patrol. Only handles from the whitelist or handles securely opened by
> functions like openFile will be accepted. Because of the opaque IO
> constructor and the restricted set of exported operations this module is not
> easily fooled.
>
> I would almost dare to say this module is conceptually safe and code with
> the jailed IO type can blindly be trusted. Except, yes unfortunately except,
> unsafePerformIO ruins it all. I would almost suggest adding a flag to the
> compiler to enforce the absence ofunsafeRuinMyTypeSafety-alike functions in
> order to be able to create systems in which code can be trusted by its type
> alone.
>
> Nonetheless, this module is one step forward in trusting your own programs.
> Some real http://tinyurl.com/paranoidpeople prefer writing there software
> in one of the most insecure programming languages and perform security
> audits by hand, I'd rather have my compiler do the job. (Anyone who wants to
> audit this library is more than welcome!)
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090827/d685a718/attachment.html