jail: Jailed IO monad.
|Dependencies||base (>=3 && <=5), containers (==0.2.*), directory (==1.0.*), monads‑fd (==0.0.*), transformers (==0.1.*) [details]|
|Uploaded||by SebastiaanVisser at Thu Aug 27 18:03:58 UTC 2009|
|Downloads||821 total (12 in the last 30 days)|
|Rating||(no votes yet) [estimated by rule of succession]|
|Status||Docs uploaded by user
Build status unknown [no reports yet]
Hackage Matrix CI
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
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 of
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 their 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!)
For package maintainers and hackage trustees