I don't think this really is what people might call a sandbox but it can optionally block or allow syscalls happening (in my mind only one aspect of a sandbox) and it looks like it's interactive. I think this is great. OpenBSD has had great success with pledge and I have been experimenting with seccomp (via the libseccomp project) with both Node.js bindings and a cli in C for doing a very similar thing as Sandy (although not interactively, which is a nice touch).
Yeah, "sandbox" is definitely a stretch, but I couldn't think of a similar but descriptive term. I've also found since posting there are definitely some easy to expose security wholes where the syscalls aren't traced in threads and child processes. So there is lots of room for improvement. I'll take a look at the projects you mentioned to see how they've tackled those issues. Thanks!
I’m not really familiar with ptrace, but does this
if regs.Orig_rax == 0 {
mean it only intercepts the read syscall? Seems like any security someone was hoping to provide with this could be bypassed entirely by accident (e.g. a script in a language that always uses readv).
Anyway if that is what it means you should probably not describe this as “to run untrusted code”.
Yes. There's a number of other ways to get around this too, one that comes to mind is mmap. Plus I'm fairly sure spawning a new thread would work as well: one because it's possible to do so without it being watched, and two because you can TOCTOU, from another thread, the registers while they're being verified.
Any blacklist-based syscall filtering solution that aims to run untrusted code is bound to be doomed, as the surface of all possible syscalls and ways they can be exploited to bypass some policy is enormous.
Poignantly, the naive approach of 'let's just block read(2) to prevent file access' doesn't work - there's multiple ways to bypass simple read(2) filtering like this. The easiest that come to mind are:
- using readv(2)
- using sendfile(2)
- sym/hardlinks to bypass path checks, and the inherent TOCTOU exploits of further naive checks
The same applies to any other policy you wish to implement, and for every one of those you need to consider the collection of all Linux syscalls and filter all of the relevant ones. There's around 300 syscalls in Linux as of writing.
Not to mention typical newbie mistakes that this project makes: not following forks, not checking for 32-bit syscalls, etc.
gVisor [1] does this well - instead of filtering, it reimplements the logic for handling Linux syscalls in userspace (eg., is actually responsible for handing out FDs and other handles, presenting the filesystem to the user, etc).
Thanks for the input, I agree and I've added a warning to the readme taking this into account and directing readers to this discussion.
I do think there is value in ease of use with something like sandy. I'm unlikely to setup gvisor just to run some arbitrary script I found online. I assume most people today just will run scripts directly on their machine. With sandy, I was experimenting if you could get 80% of the security while still making it really easy to use. I agree that it still hasn't met that mark with regards to security but I think it's possible to improve that.
>With sandy, I was experimenting if you could get 80% of the security while still making it really easy to use
This seems dangerous. That 20% insecurity is still pretty large, but small enough it makes users complacent and gives them that false '100%' secure feeling, especially when coupled with ease of use.
13 comments
[ 5.2 ms ] story [ 40.3 ms ] threadFirejail is another worthwhile alternative: https://news.ycombinator.com/item?id=12239840
I stumbled on Solo5 (runs MirageOS/IncludeOS unikernels on Linux) this past month which looked promising: https://github.com/solo5/solo5
Anyway if that is what it means you should probably not describe this as “to run untrusted code”.
Edit: A sibling comment mentioned mmap() as another workaround. That made me think of yet another....sendfile().
Poignantly, the naive approach of 'let's just block read(2) to prevent file access' doesn't work - there's multiple ways to bypass simple read(2) filtering like this. The easiest that come to mind are:
The same applies to any other policy you wish to implement, and for every one of those you need to consider the collection of all Linux syscalls and filter all of the relevant ones. There's around 300 syscalls in Linux as of writing.Not to mention typical newbie mistakes that this project makes: not following forks, not checking for 32-bit syscalls, etc.
gVisor [1] does this well - instead of filtering, it reimplements the logic for handling Linux syscalls in userspace (eg., is actually responsible for handing out FDs and other handles, presenting the filesystem to the user, etc).
[1] - https://github.com/google/gvisor
I do think there is value in ease of use with something like sandy. I'm unlikely to setup gvisor just to run some arbitrary script I found online. I assume most people today just will run scripts directly on their machine. With sandy, I was experimenting if you could get 80% of the security while still making it really easy to use. I agree that it still hasn't met that mark with regards to security but I think it's possible to improve that.
This seems dangerous. That 20% insecurity is still pretty large, but small enough it makes users complacent and gives them that false '100%' secure feeling, especially when coupled with ease of use.
https://github.com/containers/bubblewrap