[Haskell-cafe] Safe Haskell?
svenpanne at gmail.com
Thu Apr 22 20:36:29 UTC 2021
Am Do., 22. Apr. 2021 um 21:29 Uhr schrieb Joachim Durchholz <
jo at durchholz.org>:
> True, but the semantics behind each syscall can be horrendously complex.
That's correct, but a sandbox doesn't need to implement all of it. Checking
that e.g. only something below a given directory can be opened (perhaps
e.g. only for reading) is relatively easy, prohibiting creation of sockets,
limiting the amount of memory which can be mmapped (and how), etc. etc.
I can hardly imagine what could be considered "safe" for a program which
can use all of e.g. POSIX.
> That's why you can have a sandbox and this still doesn't protect you
> from symlink timing attacks on /tmp [...]
Well, if it is *your* sandbox and some processes from outside the sandbox
can change its contents arbitrarily, then you have more security issues
than simple symlink attacks.
> Instead you have to make sure that all software uses mktemp instead of
> doing nonatomic file creation&opening. [...]
Nope, one has just to make sure that the sandboxes are isolated. This is
relatively easy on the syscall level (e.g. simulating "your" own /tmp etc.).
Except that there is no such thing as an inherently safe syscall
> interface, there are unsafe ways to use it.
And that's exactly the reason why you don't give the full power of all
syscalls to a sandboxed program.
> And that's where language-based safety can help. [...]
Only if *all* of your program is written in that single language, which is
hardly the case for every non-toy program: Sooner or later you call out to
a C library, and then all bets are off.
In general: I think all security-related discussions are futile unless one
precisely defines what is considered a threat and what is considered to be
safe. And I think we agree to disagree here. :-)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe