> Run arbitrary binaries that you don't trust safely (maybe you downloaded it from the internet).
I don't think sandboxing is an appropriate solutionto this. Especially just filesystem sandboxing. This does nothing to prevent security exploits via any means.
It definitely doesn't make it safe, but it does allow you to run a binary and see what it would do to your filesystem, without actually doing it; which is pretty neat!
chroot is completely different because it completely isolates a process from the rest of the filesystem. This is more like, well, a sandbox or overlay.
I was wondering the same thing. I guess the ptrace approach is better than LD_PRELOAD, but it's still not as foolproof as a real filesystem. While this seems interesting as a ptrace learning experience, I'm not sure it actually adds any new functionality.
Interesting and cool, but I would be careful with it.
It appears to intercept a fixed list of syscalls, so it may not be intercepting all of them that are relevant. I don't think, for example, it's intercepting truncate(), so a process sandboxed in this way could still wreak a little havoc.
Not really - the child program could realize that it's on a read-only FS. But with FSSB, this is actually hidden - the program thinks it's on a regular FS (although I've recently learned that there are more advanced ways to even break this).
>some similar preload intercept
This is slightly more performant (of course, not as fast as a program without ptrace intercepts).
>Use a real virtual machine instead please
This is obviously not a full-fledged security suite ;) Just a simple, lightweight sandbox. Also this is in alpha.
Lesson learned: blacklists are catastrophic for security purposes, because you will always miss something. Even if you didn't miss anything, the next kernel release will just add something new that I can exploit.
I do something like this using systemd containers based on btrfs snapshots of my current system[1]. I have also used docker to the same end. My past experience with Ptrace based things like this tells me not to trust them. Too many ways to subtly break the program executing under you, too many ways for the program to accidentally get around your filters.
Chroot as a lot of inherent security issues. Grsec has somr fixes for it, but iirc it is not proper to trust chroot to secure you against untrusted binaries.
From what I can see a process running in that "sandbox" would happily write to a file descriptor passed into it...
Like other posters in that thread I am very skeptical that this approach can be made secure and running with acceptable performance (given there are other more practical approaches to restrict processes available (namespaces, seccomp, SELinux...).
20 comments
[ 2.1 ms ] story [ 58.4 ms ] threadI don't think sandboxing is an appropriate solutionto this. Especially just filesystem sandboxing. This does nothing to prevent security exploits via any means.
Also how does this compare to chroot?
chroot is completely different because it completely isolates a process from the rest of the filesystem. This is more like, well, a sandbox or overlay.
Clearly I need to wake up.
It appears to intercept a fixed list of syscalls, so it may not be intercepting all of them that are relevant. I don't think, for example, it's intercepting truncate(), so a process sandboxed in this way could still wreak a little havoc.
- Linux containers on a read only FS
- weaker specialised version of seccomp
- some similar preload intercept as in e.g. Gentoo sandbox (insecure, used more to catch mistakes)
- Ptrace syscall hijack (Ptrace itself is notoriously insecure)
Neither is particularly impressive. You also get support by one random guy on the Internet.
Use a real virtual machine instead please.
Not really - the child program could realize that it's on a read-only FS. But with FSSB, this is actually hidden - the program thinks it's on a regular FS (although I've recently learned that there are more advanced ways to even break this).
>some similar preload intercept
This is slightly more performant (of course, not as fast as a program without ptrace intercepts).
>Use a real virtual machine instead please
This is obviously not a full-fledged security suite ;) Just a simple, lightweight sandbox. Also this is in alpha.
Edit: done!
FWIW, I agree with the other comment - blacklists might not be the best solution here.
[1] https://wiki.archlinux.org/index.php/Systemd-nspawn#Use_Btrf...
* https://firejail.wordpress.com/
* https://news.ycombinator.com/item?id=12239840
Like other posters in that thread I am very skeptical that this approach can be made secure and running with acceptable performance (given there are other more practical approaches to restrict processes available (namespaces, seccomp, SELinux...).