[Haskell-cafe] ANN: jail-0.0.1 - Jailed IO monad
John Van Enk
vanenkj at gmail.com
Thu Aug 27 10:14:21 EDT 2009
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!
> Sebastiaan Visser
>  Source repo: http://github.com/sebastiaanvisser/jail/
>  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]
> 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe