On 02/07/2018 08:30 PM, Paul Moore wrote:
On Wed, Feb 7, 2018 at 6:12 PM, Tom Hromatka <tom.hroma...@oracle.com> wrote:
On 02/07/2018 03:17 PM, Paul Moore wrote:
* Improved performance is always good, but functional equivalency and
compatibility with the existing API/callers is another hard
requirement.  I mention this because of your comments regarding
argument filtering and hybrid BPF filters, can you elaborate a bit
more on the possible solutions to ensure this works under EBPF
(including hybrid options)?
Agreed.  We cannot afford to break existing seccomp users.

So this is purely theoretical, but I think it should work.  We could
utilize seccomp's ability in the kernel to run multiple seccomp filters.
The first filter to run would be the EBPF filter.  If it returns an
action to run, we could bail out of the for() loop in seccomp_run_filters()
early.  If not, continue running the cBPF filter(s) as usual. Existing
seccomp users wouldn't even load an EBPF filter so their behavior would
remain unchanged.

On the libseccomp side, I would expect something like this:

int sys_filter_load(struct db_filter_col *col)
{
     int rc;

     /* load the classic BPF filter first */
     rc = sys_bpf_filter_load(col);
     if (rc < 0)
         return rc;

     /* process the EBPF filter.  note - it will only load a
      * filter if it has been instructed to do so by the user.
      * for classic seccomp filters this is effectively a nop
      */
     rc = sys_ebpf_filter_load(col);

     return rc;
}
One of the gotchas with loading multiple filters is that the first,
and all non-final, filters need to allow the syscalls necessary to
load the additional filter (I'm not 100% on EBPF, but I believe it is
still just seccomp(2)).  Generally this is user/caller problem, but if
we are hiding the fact that we are loading two filters instead of one
we are going to need to do some additional work to ensure we can load
the second filter and not allow any syscalls the caller didn't intend.

You are definitely correct.  The cBPF filter would have to
(at a minimum) allow __NR_seccomp and __NR_bpf.  __NR_bpf is
used to create and populate the EBPF map.

If a user was especially security conscious, they would then
need to block those syscalls in the EBPF map.  This is
potentially error prone and slightly cumbersome.


It might be a better use of time and energy to look into improving
libseccomp's filter generation, e.g. Kees' comments around
sorted-trees/qsort.



--
You received this message because you are subscribed to the Google Groups 
"libseccomp" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to libseccomp+unsubscr...@googlegroups.com.
To post to this group, send email to libseccomp@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to