Re: FWIW: sysrestrict

[Thor Lancelot Simon <tls%panix.com@localhost>]

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