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