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

[1] - https://github.com/google/gvisor

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.

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

Take a look at MIT's Mbox: https://news.ycombinator.com/item?id=7214419

Firejail 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

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!

"Sandboxing" and "untrusted code" usually carry security connotations. I'd suggest you advertise this as instrumentation or tracing instead.

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.

Yes, that's right, SYS_READ is 0. So pread(), readv() and preadv() would go around this.

Edit: A sibling comment mentioned mmap() as another workaround. That made me think of yet another....sendfile().

The coolest thing about this read is the idea of a free-beer.bounty lowkey CTF file in my home dir.

SandFS does not rely on PTRACE, but uses eBPF. No TOCTTOU races. https://lwn.net/Articles/803890/

See also bubblewrap

https://github.com/containers/bubblewrap