Am Do., 22. Apr. 2021 um 21:29 Uhr schrieb Joachim Durchholz < jo@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. :-)