Show HN: FSSB – A filesystem sandbox for Linux | Hacker News Reader

Show HN: FSSB – A filesystem sandbox for Linux

github.com

43 pointsadtac20 comments

  $ cat > nope.c <<EOF
  > #include <stdio.h>
  > void main() { 
  >         write(creat("nope.nope"), "oh no\n", 6);
  > }
  > EOF
  $ make nope
  $ ./fssb -- ./nope
  fssb: child exited with 4
  fssb: sandbox directory: /tmp/fssb-2/
  $ cat nope.nope
  oh no

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.

Ugh, I forgot about `creat`. Should be an easy fix though :)

Edit: done!

FWIW, I agree with the other comment - blacklists might not be the best solution here.

Use of ptrace will incur a huge performance penalty. Why not just using a mount namespace and using an overlay filesystem?

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.

> 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.

Also how does this compare to chroot?

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.

it could hardened it with seccomp filter.

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.

[1] https://wiki.archlinux.org/index.php/Systemd-nspawn#Use_Btrf...

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.

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...).