
If you can execute subprocesses, you could always spawn gdb to attach via ptrace() to the parent process and then poke around memory. Yes this is a "dumb" example but I think it goes to show how important it is to correctly characterize what the threat model is. A "no-segfault" fragment of Haskell doesn't seem so much as a security feature as it is a "good practices" lint pass. Edward Excerpts from Ryan Newton's message of 2016-08-09 10:41:44 -0400:
On Mon, Aug 8, 2016 at 8:46 PM, Mikhail Glushenkov
wrote: Yes, this can be done with JNI, see e.g. [1]. Additionally, by using sun.misc.Unsafe [2], one can cause segfaults even from pure Java. [1] https://www.cs.princeton.edu/~appel/papers/safejni.pdf [2] http://www.inf.usi.ch/faculty/lanza/Downloads/Mast2015a.pdf
Ah, I see. I thought that, ruling out FFI, that you couldn't segfault with pure Java code. Good to know about the unsafe interface.
On Mon, Aug 8, 2016 at 7:32 PM, David Terei
wrote: If you have the energy, it'd be great to put some of this thinking into a wiki page (https://ghc.haskell.org/trac/ghc/wiki/SafeHaskell) and flesh out a first approximation of what IO API's cause issues. Is it just Ptr not carrying bounds around with it? Maybe, but then we need to secure how Ptr's can be created, which excludes FFI returning Ptr's.
Yes, we can add a Wiki page.
Btw I was thinking more of kicking FFI/peek/poke outside of the Safe bubble, not changing their operational behavior. First of all, it's nigh impossible to lock down FFI calls.
When someone, e.g. Bob Harper https://existentialtype.wordpress.com/2012/08/14/haskell-is-exceptionally-un..., points out a problem in Haskell, we sometimes respond "hey, *Safe Haskell* is the real objet d'art! It's a safe language." Yet it isn't really a full *language* if people cannot write and run programs in it! (Because every program must be ultimately be `main::IO()`.) Kicking out segfaulty features would still leave a safe language that people can write complete programs in.
Best, -Ryan