[Haskell-cafe] Safe Haskell?

[Sven Panne]

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...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20210422/c21af897/attachment.html>