$ cat > nope.c #include
> 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 noShow HN: FSSB – A filesystem sandbox for Linux
11–20 of 21 posts
Re: Show HN: FSSB – A filesystem sandbox for Linux
#12$ cat > nope.c #include > 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.
Re: Show HN: FSSB – A filesystem sandbox for Linux
#13Use 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.
Re: Show HN: FSSB – A filesystem sandbox for Linux
#14I 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...
Re: Show HN: FSSB – A filesystem sandbox for Linux
#15Is this somehow better than chroot?
Re: Show HN: FSSB – A filesystem sandbox for Linux
#16See also: Firejail
Re: Show HN: FSSB – A filesystem sandbox for Linux
#17$ cat > nope.c #include > 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
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.
Re: Show HN: FSSB – A filesystem sandbox for Linux
#18This 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 plea…
>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.
Re: Show HN: FSSB – A filesystem sandbox for Linux
#19From 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...).
Re: Show HN: FSSB – A filesystem sandbox for Linux
#20This looks like Gentoo's sandbox. Except Gentoo is a whitelist iirc