APPLIED: [Precise][Pull Request] SECCOMP mode 2, BPF

[Will Drewry]

On Mon, Mar 26, 2012 at 9:21 PM, Tim Gardner <rtg.canonical at gmail.com> wrote:
> On 03/23/2012 12:14 AM, Kees Cook wrote:
>>
>> Hi,
>>
>> On Thu, Mar 22, 2012 at 01:43:57PM -0500, Will Drewry wrote:
>>>
>>> On Thu, Mar 22, 2012 at 8:07 AM, Tim Gardner<tim.gardner at canonical.com>
>>>  wrote:
>>>>
>>>> On 03/21/2012 02:35 PM, Kees Cook wrote:
>>>>>
>>>>> On Wed, Mar 21, 2012 at 02:28:33PM -0600, Tim Gardner wrote:
>>>>>>
>>>>>> Applied for now pending Leann's opinion. I've made a first pass
>>>>>> review.
>>>>>> Some of it is a bit dense. I'll have another look tomorrow.
>>>>>
>>>>>
>>>>> Thanks! I'm happy to field any questions about it, if that helps, and
>>>>> if I can't answer them, I'm sure Will can. :)
>>>>
>>>>
>>>> So I guess it got uploaded. How about a quick description of how to
>>>> utilize the seccomp filter?
>>>> [...]
>>>> In the meantime I guess I'll go read the seccomp patch to the
>>>> Documentation directory.
>>>
>>>
>>> If the docs can be made more coherent, I'm more than happy to change them
>>> up.
>>
>>
>> I've put together a little tutorial (with working code samples) on using
>> basic syscall filtering via seccomp filter here:
>>
>> http://outflux.net/teach-seccomp/
>>
>> -Kees
>>
>
> Kees - I've read through your tutorial. Thanks by the way for that. With
> regard to determining seccomp BPF functionality, do you think its sufficient
> to just test for one or two syscalls ? That will at least indicate that the
> seccomp subsystem is alive and functional. We could almost just use your
> example program for that.

In general, I think that's enough.  If you want, I finally finished
porting my organically developed tests into something a "little" bit
prettier and arch agnostic which might be useful:
  https://github.com/redpig/seccomp/tree/master/tests

I believe all the tests will pass for the patch series merged, except
for one, where I tightened the mask on the return values (in a
to-be-posted v17).  No userspace code ABI changes specifically, just
ensuring a hard cap on the highest BPF return value, so nothing scary
:)

> Is there benefit to performing an exhaustive syscall filter test, or are all
> syscalls treated the same ?

Yup - the BPF is basically just a userspace API for syscall-time use
of syscall_get_number and syscall_get_arguments, and syscall_get_arch.
 So once you've grabbed one syscall number, you could've grabbed any
of them :)


The tests above don't explore all the argument edge cases,
architecture values, etc, but it covers a large amount of the ground
and fills in gaps where the kernel/samples/seccomp and Kees's tutorial
don't touch explicitly.

cheers!
will