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

Tim Gardner rtg.canonical at gmail.com
Tue Mar 27 02:21:04 UTC 2012


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.

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

rtg

P.S. I know I should just go look at the code, but I'm feeling kinda 
lazy tonight.
-- 
Tim Gardner tim.gardner at canonical.com




More information about the kernel-team mailing list