
Show HN: FSSB – A filesystem sandbox for Linux - adtac
https://github.com/adtac/fssb
======
__michaelg

      $ 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

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

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

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

------
gravypod
> 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?

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

~~~
Mic92
it could hardened it with seccomp filter.

------
Skunkleton
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...](https://wiki.archlinux.org/index.php/Systemd-
nspawn#Use_Btrfs_subvolume_as_container_root)

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

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

------
chocolateboy
See also: Firejail

* [https://firejail.wordpress.com/](https://firejail.wordpress.com/)

* [https://news.ycombinator.com/item?id=12239840](https://news.ycombinator.com/item?id=12239840)

------
Mic92
There was a project which pursue a similar strategy:
[https://github.com/tsgates/mbox](https://github.com/tsgates/mbox)

------
AstralStorm
This is essentially the same thing as either of:

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

~~~
adtac
>Linux containers on a read only FS

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.

------
e2kp
This looks like Gentoo's sandbox. Except Gentoo is a whitelist iirc

------
nisse72
Is this somehow better than chroot?

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

------
X86BSD
I can't even tell what this does. I just woke up but is this like capsicum on
freebsd,
[https://m.youtube.com/watch?v=raNx9L4VH2k](https://m.youtube.com/watch?v=raNx9L4VH2k),
or jails in the FS, or both?

Clearly I need to wake up.

~~~
tyingq
It's intercepting specific system calls via ptrace() and dynamically changing
the arguments passed to them. I believe freebsd has ptrace.

