dev-haskell/jail (haskell)

Search

Package Information

Description:
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 of @unsafeRuinMyTypeSafety@-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 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!)
Homepage:
https://hackage.haskell.org/package/jail
License:
BSD

Versions

Version EAPI Keywords Slot
0.0.1.1-r4 8 ~amd64 0

Metadata

Description

Maintainers

Raw Metadata XML
<pkgmetadata>
	<maintainer type="project">
		<email>haskell@gentoo.org</email>
		<name>Gentoo Haskell</name>
	</maintainer>
	<longdescription>
		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:
		
		&gt; 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:
		
		&gt; 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 of @unsafeRuinMyTypeSafety@-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 &lt;http://tinyurl.com/paranoidpeople&gt;
		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!)
	</longdescription>
</pkgmetadata>

Lint Warnings

Files

Manifest

Type File Size Versions
Unmatched Entries
Type File Size
DIST jail-0.0.1.1.tar.gz 6233 bytes