Candidate replacement approach for seccomp_filter (no ftrace)

[Will Drewry]

On Fri, Jan 27, 2012 at 8:09 AM, Stefan Bader
<stefan.bader at canonical.com> wrote:
> On 11.01.2012 18:31, Will Drewry wrote:
>> Hiya ubuntu kernel team,
>>
>> I've just posted a new round of seccomp_filter patches.  I'm taking a
>> wholly different tack which I think is both much saner than the
>> original patch series and is easier to maintain if upstream never
>> accepts it.  I'd certainly love your feedback and thoughts about
>> possible viability given that you were kind enough to pick up my
>> original patch series.  (I'm most certainly happy to help if I can to
>> avoid too much pain, but I realize there are no consumers of
>> seccomp_filter on ubuntu yet :)
>>
>> That aside, they have been sent to linux-kernel:
>>   marc.info/?l=linux-kernel&m=132630290817221&w=2
>>   marc.info/?l=linux-kernel&m=132630294217251&w=2
>>   marc.info/?l=linux-kernel&m=132630293217243&w=2
>>
>> Cheers!
>> will
>>
> Yesterday I got pinged about some potential regression on EC2[1]. Looking at the
> traces I saw seccomp code being the cause (this is the old patchset in 12.04
> Precise). Then I checked a bit more and found that this also seems to happen on
> older Precise kernels and actually on bare metal as well (64bit). Not sure
> whether this is triggered by changes to the qa regression test suite or just has
> been missed all the time.
>
> So I went ahead and reverted anything we had in precise that was labeled seccomp
> and picked the two patches Will had posted to LKLM. Having build a kernel with
> those and re-run the tests (Sidenote: any reason why befs is used for some
> subtest? Cause that is now in the extra modules package for virtual).
> Using that kernel I would not see any Oops but some of the subtests are failing.
> Now I am not sure this is because something is wrong in the patch or in the
> test. Could be just looking at a feature that is not (yet) implemented.

Most likely it is the gap between the last public post and what was
pulled from the chromium-os tree.  In order to support the LXC case, I
added inheritance for CAP_SYS_ADMIN processes, so I wouldn't be
surprised if those fail.

It also looks like CONFIG_FTRACE_SYSCALLS is not enabled on the above
kernel either since all of the ftrace tests that should pass fail.
I'd guess both of these issues are causing the failures.

> Given, the oops and that there is the new approach, I think we want to
> concentrate on the new set. The discussion about that was longer and I have not
> looked to closely. Will, is there already a newer version of this?

Yes! I just got "cross"-arch userspace tooling working last night. I
am cleaning up the patch series and reposting today.  I hope that's
not too late!  The biggest challenge is the no_new_privs patch.  I can
either push up a version with seccomp_check_exec() again or I can
leave it dependent on luto's no_new_privs if you think that will be
picked up too.  Either way is fine for me.  (The seccomp_check_exec()
is a quite small change.)

Thanks!
will

>
> -Stefan
>
> ======================================================================
> FAIL: test_110_seccomp_filter (__main__.KernelSecurityTest)
> seccomp_filter works
> ----------------------------------------------------------------------
> Traceback (most recent call last):
>  File "./test-kernel-security.py", line 1385, in test_110_seccomp_filter
>    shelltimeout(expected, ["./seccomp_tests"])
>  File "/home/ubuntu/qa-regression-test/testlib.py", line 1102, in __call__
>    result = self.function(*args, **kwargs)
>    self.assertEquals(expected, rc, msg + result + report)
> AssertionError: Got exit code 1, expected 0
> Command: './seccomp_tests'
> Output:
> PASS :: mode_one_ok
> PASS :: mode_one_kill
> PASS :: mode_one_ok
> PASS :: mode_one_kill
> PASS :: add_filter_too_long
> PASS :: mode_one_ok
> PASS :: mode_one_kill
> PASS :: add_filter_too_long
> PASS :: add_filter_too_short
> PASS :: mode_one_ok
> PASS :: mode_one_kill
> PASS :: add_filter_too_long
> PASS :: add_filter_too_short
> PASS :: add_filter_null
> PASS :: add_bool_apply
> PASS :: add_bool_apply_event
> Failed to enter mode 2: -1
> prctl: Bad address
> Read in:
> write: Bad address
> PASS :: mode_one_ok
> PASS :: mode_one_kill
> PASS :: add_filter_too_long
> PASS :: add_filter_too_short
> PASS :: add_filter_null
> PASS :: add_bool_apply
> PASS :: add_bool_apply_event
> FAIL :: add_bool_apply_fail
> FAIL :: add_bool_apply_get
> PASS :: add_bool_apply_add
> PASS :: add_bool_apply_drop
> FAIL :: add_bool_apply_drop_die
> PASS :: add_ftrace_apply
> FAIL :: add_ftrace_apply_fail
> FAIL :: add_ftrace_apply_get
> FAIL :: add_ftrace_apply_append_get
> PASS :: mode_one_ok
> PASS :: mode_one_kill
> PASS :: add_filter_too_long
> PASS :: add_filter_too_short
> write: Bad address
> PASS :: mode_one_ok
> PASS :: mode_one_kill
> PASS :: add_filter_too_long
> PASS :: add_filter_too_short
> PASS :: add_filter_null
> PASS :: add_bool_apply
> PASS :: add_bool_apply_event
> FAIL :: add_bool_apply_fail
> FAIL :: add_bool_apply_get
> PASS :: add_bool_apply_add
> PASS :: add_bool_apply_drop
> FAIL :: add_bool_apply_drop_die
> PASS :: add_ftrace_apply
> FAIL :: add_ftrace_apply_fail
> FAIL :: add_ftrace_apply_get
> FAIL :: add_ftrace_apply_append_get
> PASS :: mode_one_ok
> PASS :: mode_one_kill
> PASS :: add_filter_too_long
> PASS :: add_filter_too_short
> PASS :: add_filter_null
> PASS :: add_bool_apply
> PASS :: add_bool_apply_event
> FAIL :: add_bool_apply_fail
> FAIL :: add_bool_apply_get
> PASS :: add_bool_apply_add
> PASS :: add_bool_apply_drop
> FAIL :: add_bool_apply_drop_die
> PASS :: add_ftrace_apply
> FAIL :: add_ftrace_apply_fail
> FAIL :: add_ftrace_apply_get
> FAIL :: add_ftrace_apply_append_get
> FAIL :: add_drop_ftrace_proc
> FAIL :: keep_exec
> FAIL :: keep_exec_drop
> FAIL :: lose_exec
>
> [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/921816