Cool! However, it does not protect me from doing System.IO.Unsafe.unsafePerformIO in whatever fashion I like, does it?
2009/8/27 Sebastiaan Visser <sfvis...@cs.uu.nl>: > 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@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Eugene Kirpichov Web IR developer, market.yandex.ru _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe