Sandboxing in Linux with zero lines of code (Cloudflare blog)
([Security] Jul 8, 2020 14:36 UTC (Wed) (corbet))
- Reference: 0000825547
- News link: https://lwn.net/Articles/825547/
- Source link:
The Cloudflare blog is running [1]an overview of sandboxing with seccomp() , culminating in a tool written there to sandbox any existing program. " We really liked the 'zero code seccomp' approach with systemd SystemCallFilter= directive, but were not satisfied with its limitations. We decided to take it one step further and make it possible to prohibit any system call in any process externally without touching its source code, so came up with the Cloudflare sandbox. It’s a simple standalone toolkit consisting of a shared library and an executable. The shared library is supposed to be used with dynamically linked applications and the executable is for statically linked applications. "
[1] https://blog.cloudflare.com/sandboxing-in-linux-with-zero-lines-of-code/
[1] https://blog.cloudflare.com/sandboxing-in-linux-with-zero-lines-of-code/
Sandboxing in Linux with zero lines of code (Cloudflare blog)
I hacked a prototype of a sandboxing utility for Linux a few years ago, that took a different approach: it would patch an ELF executable, divert the entry point to a routine that would install the seccomp profile, and then proceed to execute the original _start() function. While the idea worked fine ( [1]https://tia.mat.br/posts/2016/11/08/infect_to_protect.html for the blog post), there are some caveats in relying only on seccomp-bpf for sandboxing... it's just a piece of the puzzle. Determining which syscalls a program makes it a pretty big challenge, as it can change any time due to a changed library (or even the kernel, if a VDSO changes, for instance).
[1] https://tia.mat.br/posts/2016/11/08/infect_to_protect.html
Sandboxing in Linux with zero lines of code (Cloudflare blog)
I hacked a prototype of a sandboxing utility for Linux a few years ago, that took a different approach: it would patch an ELF executable, divert the entry point to a routine that would install the seccomp profile, and then proceed to execute the original _start() function. While the idea worked fine ( [1]https://tia.mat.br/posts/2016/11/08/infect_to_protect.html for the blog post), there are some caveats in relying only on seccomp-bpf for sandboxing... it's just a piece of the puzzle. Determining which syscalls a program makes it a pretty big challenge, as it can change any time due to a changed library (or even the kernel, if a VDSO changes, for instance).
[1] https://tia.mat.br/posts/2016/11/08/infect_to_protect.html
Sandboxing in Linux with zero lines of code (Cloudflare blog)
... except that that LD_PRELOAD approach they're suggesting is fundamentally unsafe - if opening the LD_PRELOAD library fails (e.g. with -ENFILE, because the global limit on the number of open files was reached for a short moment), glibc will just print a warning and continue without enabling the sandbox:
$ strace -E LD_PRELOAD=/foo/bar/baz -e trace=openat -e inject=openat:error=ENFILE:when=1 echo foobar
openat(AT_FDCWD, "/foo/bar/baz", O_RDONLY|O_CLOEXEC) = -1 ENFILE (Too many open files in system) (INJECTED)
ERROR: ld.so: object '/foo/bar/baz' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
foobar
+++ exited with 0 +++ See [1]https://github.com/cloudflare/sandbox/issues/1 .
[1] https://github.com/cloudflare/sandbox/issues/1