[cap-talk] Abstractions that subsume capabilities
Kevin Reid
kpreid at mac.com
Wed Mar 12 10:42:13 EDT 2008
On Mar 12, 2008, at 0:04, Richard Uhtenwoldt wrote:
> import IO
> main = do
> handle <- openFile "/etc/passwd" ReadMode
> contents <- hGetContents handle
> flip mapM_ (lines contents)
> (\ line -> hPutStrLn stdout line)
>
> Here is untested E code which does the same thing. Observe that it
> is almost identical except for syntax and the names of the input/
> output operations.
>
> def handle := <file:/etc/passwd>
> def contents := handle.getText()
> for line in contents.split("\n") {
> println(line)
> }
...
> Since I found the E code in the E Idioms Quick Reference Card, I
> assume you all regard it as good, attack-resistant code. But
> obviously if it does not need surgery to make it more attack-
> resistant, the Haskell code does not either.
There is a difference. In the E code, it makes use of file__uriGetter
from the lexical scope. In order to have security, there must exist
lexical scopes which do not contain it (in which code which should
not start out with total filesystem access may be evaluated). In
Haskell, this is not the case because any Haskell module can "import
IO".
It would be *sufficient*, to produce a sandboxed-Haskell, to add a
restriction on what modules may be imported -- lambdabot the
evaluating IRC bot is an existence proof of this.
However, in order to write capability-structured programs, there must
also be tools to perform proper subdivisions of authority -- such as
the (//) operator in my previous code, which produces subdirectory
capabilities. That is the aspect of Haskell's libraries which would
most need to be changed or extended.
(A fine point: what you call "handle" in the two programs is
different. In the Haskell program, it is an *open* file -- a Unix
file descriptor, etc. In the E program, it is an *unopened* file --
it gives permission to open the file, or to delete it, or access
files under it if it's a directory, etc. .getText() is the equivalent
of readFile, not hGetContents.)
--
Kevin Reid <http://homepage.mac.com/kpreid/>
More information about the cap-talk
mailing list