On Sat, Jul 23, 2016 at 03:52:03PM -0700, Alistair Crooks wrote: > > My main problem is that simply outlawing system calls is a very > coarse-grained hammer. I may want a binary to be able to open files > for writing in /tmp, but not open any files in /etc for writing. Or > reading files in my home directory, except for anything in ~/.ssh or > ~/.gnupg. How does sysrestrict cope with this?
Having been down this path before, I agree. In particular, though you might think you could get somewhere by forbidding the system calls that return new file descriptors, this turns out to break most programs that weren't specially written to work with sysrestrict (which we called something else, but it was the same thing). When I did this before, we ended up with something roughly like sysrestrict plus a set of restrictions on each system call that could return a new fd. The ones to do with networking had to be a little more subtle. It is also probably necessary to restrict mmap() but that is even harder. However, with all that done, I think a system like this could even allow you to prove many useful properties about the impact of a particular program on system security under realistic assumptions. We did use kauth; I considered using a bitmap like yours to short-circuit the logic for calls with no restrictions, but for my application kauth was fast enough. I do like baking the restrictions into the binary. Thor