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

[Sebastiaan Visser]

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!)