On Sun, May 31, 2020 at 02:03:48PM -0700, Andy Lutomirski wrote: > On Sun, May 31, 2020 at 11:57 AM Andy Lutomirski <luto@xxxxxxxxxx> wrote: > > > > > > What if there was a special filter type that ran a BPF program on each > > syscall, and the program was allowed to access user memory to make its > > decisions, e.g. to look at some list of memory addresses. But this > > would explicitly *not* be a security feature -- execve() would remove > > the filter, and the filter's outcome would be one of redirecting > > execution or allowing the syscall. If the "allow" outcome occurs, > > then regular seccomp filters run. Obviously the exact semantics here > > would need some care. > > Let me try to flesh this out a little. > > A task could install a syscall emulation filter (maybe using the > seccomp() syscall, maybe using something else). There would be at > most one such filter per process. Upon doing a syscall, the kernel > will first do initial syscall fixups (e.g. SYSENTER/SYSCALL32 magic > argument translation) and would then invoke the filter. The filter is > an eBPF program (sorry Kees) and, as input, it gets access to the FWIW, I agree: something like this needs to use eBPF -- this isn't being designed as a security boundary. It's more like eBPF ptrace. > task's register state and to an indication of which type of syscall > entry this was. This will inherently be rather architecture specific > -- x86 choices could be int80, int80(translated), and syscall64. (We > could expose SYSCALL32 separately, I suppose, but SYSENTER is such a > mess that I'm not sure this would be productive.) The program can > access user memory, and it returns one of two results: allow the > syscall or send SIGSYS. If the program tries to access user memory > and faults, the result is SIGSYS. > > (I would love to do this with cBPF, but I'm not sure how to pull this > off. Accessing user memory is handy for making the lookup flexible > enough to detect Windows vs Linux. It would be *really* nice to > finally settle the unprivileged eBPF subset discussion so that we can > figure out how to make eBPF work here.) And yes, this is the next road-block: finding a way to safely do unprivileged eBPF. -- Kees Cook
