6 ms·

Show HN: FSSB – A filesystem sandbox for Linux

43 points by adtac 10y ago

gravypod 10y ago
> 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 10y ago
  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 10y ago
    it could hardened it with seccomp filter.
X86BSD 10y ago
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 10y ago
  It's intercepting specific system calls via ptrace() and dynamically changing the arguments passed to them. I believe freebsd has ptrace.
vbernat 10y ago
Use of ptrace will incur a huge performance penalty. Why not just using a mount namespace and using an overlay filesystem?
- notacoward 10y ago
  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.
Mic92 10y ago
There was a project which pursue a similar strategy: https://github.com/tsgates/mbox https://github.com/tsgates/mbox
tyingq 10y ago
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.
AstralStorm 10y ago
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 10y ago
  >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.
__michaelg 10y ago
$ 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 10y ago
  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.
- adtac 10y ago
  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.
Skunkleton 10y ago
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_Btrfs_subvolume_as_container_root https://wiki.archlinux.org/index.php/Systemd-nspawn#Use_Btrf...
nisse72 10y ago
Is this somehow better than chroot?
- e2kp 10y ago
  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.
chocolateboy 10y ago
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
Rondom 10y ago
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...).
e2kp 10y ago
This looks like Gentoo's sandbox. Except Gentoo is a whitelist iirc

43 points by adtac 10y ago

> 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 10y ago
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 10y ago
  it could hardened it with seccomp filter.

X86BSD 10y ago

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 10y ago
It's intercepting specific system calls via ptrace() and dynamically changing the arguments passed to them. I believe freebsd has ptrace.

vbernat 10y ago

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

notacoward 10y ago
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.

Mic92 10y ago

There was a project which pursue a similar strategy: https://github.com/tsgates/mbox https://github.com/tsgates/mbox

tyingq 10y ago

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.

AstralStorm 10y ago

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 10y ago
>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.

__michaelg 10y ago

$ 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 10y ago
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.
adtac 10y ago
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.

Skunkleton 10y ago

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_Btrfs_subvolume_as_container_root https://wiki.archlinux.org/index.php/Systemd-nspawn#Use_Btrf...

nisse72 10y ago

Is this somehow better than chroot?

e2kp 10y ago
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.

chocolateboy 10y ago

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

Rondom 10y ago

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

e2kp 10y ago

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