This patch is the first step in enabling checkpoint/restore of processes
with seccomp enabled.
One of the things CRIU does while dumping tasks is inject code into them
via ptrace to collect information that is only available to the process
itself. However, if we are in a seccomp mode where these processes are
prohibited from making these syscalls, then what CRIU does kills the task.
This patch adds a new ptrace option, PTRACE_O_SUSPEND_SECCOMP, that enables
a task from the init user namespace which has CAP_SYS_ADMIN and no seccomp
filters to disable (and re-enable) seccomp filters for another task so that
they can be successfully dumped (and restored). We restrict the set of
processes that can disable seccomp through ptrace because although today
ptrace can be used to bypass seccomp, there is some discussion of closing
this loophole in the future and we would like this patch to not depend on
that behavior and be future proofed for when it is removed.
Note that seccomp can be suspended before any filters are actually
installed; this behavior is useful on criu restore, so that we can suspend
seccomp, restore the filters, unmap our restore code from the restored
process' address space, and then resume the task by detaching and have the
filters resumed as well.
v2 changes:
* require that the tracer have no seccomp filters installed
* drop TIF_NOTSC manipulation from the patch
* change from ptrace command to a ptrace option and use this ptrace option
as the flag to check. This means that as soon as the tracer
detaches/dies, seccomp is re-enabled and as a corrollary that one can not
disable seccomp across PTRACE_ATTACHs.
v3 changes:
* get rid of various #ifdefs everywhere
* report more sensible errors when PTRACE_O_SUSPEND_SECCOMP is incorrectly
used
v4 changes:
* get rid of may_suspend_seccomp() in favor of a capable() check in ptrace
directly
Signed-off-by: Tycho Andersen <[email protected]>
CC: Kees Cook <[email protected]>
CC: Andy Lutomirski <[email protected]>
CC: Will Drewry <[email protected]>
CC: Roland McGrath <[email protected]>
CC: Oleg Nesterov <[email protected]>
CC: Pavel Emelyanov <[email protected]>
CC: Serge E. Hallyn <[email protected]>
---
include/linux/ptrace.h | 1 +
include/uapi/linux/ptrace.h | 6 ++++--
kernel/ptrace.c | 9 +++++++++
kernel/seccomp.c | 8 ++++++++
4 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
index 987a73a..061265f 100644
--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -34,6 +34,7 @@
#define PT_TRACE_SECCOMP PT_EVENT_FLAG(PTRACE_EVENT_SECCOMP)
#define PT_EXITKILL (PTRACE_O_EXITKILL << PT_OPT_FLAG_SHIFT)
+#define PT_SUSPEND_SECCOMP (PTRACE_O_SUSPEND_SECCOMP << PT_OPT_FLAG_SHIFT)
/* single stepping state bits (used on ARM and PA-RISC) */
#define PT_SINGLESTEP_BIT 31
diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h
index cf1019e..a7a6979 100644
--- a/include/uapi/linux/ptrace.h
+++ b/include/uapi/linux/ptrace.h
@@ -89,9 +89,11 @@ struct ptrace_peeksiginfo_args {
#define PTRACE_O_TRACESECCOMP (1 << PTRACE_EVENT_SECCOMP)
/* eventless options */
-#define PTRACE_O_EXITKILL (1 << 20)
+#define PTRACE_O_EXITKILL (1 << 20)
+#define PTRACE_O_SUSPEND_SECCOMP (1 << 21)
-#define PTRACE_O_MASK (0x000000ff | PTRACE_O_EXITKILL)
+#define PTRACE_O_MASK (\
+ 0x000000ff | PTRACE_O_EXITKILL | PTRACE_O_SUSPEND_SECCOMP)
#include <asm/ptrace.h>
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index c8e0e05..11fa460 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -556,6 +556,15 @@ static int ptrace_setoptions(struct task_struct *child, unsigned long data)
if (data & ~(unsigned long)PTRACE_O_MASK)
return -EINVAL;
+ if (unlikely(data & PTRACE_O_SUSPEND_SECCOMP)) {
+ if (!config_enabled(CONFIG_CHECKPOINT_RESTORE) ||
+ !config_enabled(CONFIG_SECCOMP))
+ return -EINVAL;
+
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+ }
+
/* Avoid intermediate state when all opts are cleared */
flags = child->ptrace;
flags &= ~(PTRACE_O_MASK << PT_OPT_FLAG_SHIFT);
diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 980fd26..645e42d 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -590,6 +590,10 @@ void secure_computing_strict(int this_syscall)
{
int mode = current->seccomp.mode;
+ if (config_enabled(CONFIG_CHECKPOINT_RESTORE) &&
+ unlikely(current->ptrace & PT_SUSPEND_SECCOMP))
+ return;
+
if (mode == 0)
return;
else if (mode == SECCOMP_MODE_STRICT)
@@ -691,6 +695,10 @@ u32 seccomp_phase1(struct seccomp_data *sd)
int this_syscall = sd ? sd->nr :
syscall_get_nr(current, task_pt_regs(current));
+ if (config_enabled(CONFIG_CHECKPOINT_RESTORE) &&
+ unlikely(current->ptrace & PT_SUSPEND_SECCOMP))
+ return SECCOMP_PHASE1_OK;
+
switch (mode) {
case SECCOMP_MODE_STRICT:
__secure_computing_strict(this_syscall); /* may call do_exit */
--
2.1.4
On Tue, Jun 9, 2015 at 5:49 PM, Tycho Andersen
<[email protected]> wrote:
> This patch is the first step in enabling checkpoint/restore of processes
> with seccomp enabled.
>
> One of the things CRIU does while dumping tasks is inject code into them
> via ptrace to collect information that is only available to the process
> itself. However, if we are in a seccomp mode where these processes are
> prohibited from making these syscalls, then what CRIU does kills the task.
>
> This patch adds a new ptrace option, PTRACE_O_SUSPEND_SECCOMP, that enables
> a task from the init user namespace which has CAP_SYS_ADMIN and no seccomp
> filters to disable (and re-enable) seccomp filters for another task so that
> they can be successfully dumped (and restored). We restrict the set of
> processes that can disable seccomp through ptrace because although today
> ptrace can be used to bypass seccomp, there is some discussion of closing
> this loophole in the future and we would like this patch to not depend on
> that behavior and be future proofed for when it is removed.
>
> Note that seccomp can be suspended before any filters are actually
> installed; this behavior is useful on criu restore, so that we can suspend
> seccomp, restore the filters, unmap our restore code from the restored
> process' address space, and then resume the task by detaching and have the
> filters resumed as well.
>
> v2 changes:
>
> * require that the tracer have no seccomp filters installed
> * drop TIF_NOTSC manipulation from the patch
> * change from ptrace command to a ptrace option and use this ptrace option
> as the flag to check. This means that as soon as the tracer
> detaches/dies, seccomp is re-enabled and as a corrollary that one can not
> disable seccomp across PTRACE_ATTACHs.
>
> v3 changes:
>
> * get rid of various #ifdefs everywhere
> * report more sensible errors when PTRACE_O_SUSPEND_SECCOMP is incorrectly
> used
>
> v4 changes:
>
> * get rid of may_suspend_seccomp() in favor of a capable() check in ptrace
> directly
>
> Signed-off-by: Tycho Andersen <[email protected]>
> CC: Kees Cook <[email protected]>
> CC: Andy Lutomirski <[email protected]>
> CC: Will Drewry <[email protected]>
> CC: Roland McGrath <[email protected]>
> CC: Oleg Nesterov <[email protected]>
> CC: Pavel Emelyanov <[email protected]>
> CC: Serge E. Hallyn <[email protected]>
> ---
> include/linux/ptrace.h | 1 +
> include/uapi/linux/ptrace.h | 6 ++++--
> kernel/ptrace.c | 9 +++++++++
> kernel/seccomp.c | 8 ++++++++
> 4 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
> index 987a73a..061265f 100644
> --- a/include/linux/ptrace.h
> +++ b/include/linux/ptrace.h
> @@ -34,6 +34,7 @@
> #define PT_TRACE_SECCOMP PT_EVENT_FLAG(PTRACE_EVENT_SECCOMP)
>
> #define PT_EXITKILL (PTRACE_O_EXITKILL << PT_OPT_FLAG_SHIFT)
> +#define PT_SUSPEND_SECCOMP (PTRACE_O_SUSPEND_SECCOMP << PT_OPT_FLAG_SHIFT)
>
> /* single stepping state bits (used on ARM and PA-RISC) */
> #define PT_SINGLESTEP_BIT 31
> diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h
> index cf1019e..a7a6979 100644
> --- a/include/uapi/linux/ptrace.h
> +++ b/include/uapi/linux/ptrace.h
> @@ -89,9 +89,11 @@ struct ptrace_peeksiginfo_args {
> #define PTRACE_O_TRACESECCOMP (1 << PTRACE_EVENT_SECCOMP)
>
> /* eventless options */
> -#define PTRACE_O_EXITKILL (1 << 20)
> +#define PTRACE_O_EXITKILL (1 << 20)
> +#define PTRACE_O_SUSPEND_SECCOMP (1 << 21)
>
> -#define PTRACE_O_MASK (0x000000ff | PTRACE_O_EXITKILL)
> +#define PTRACE_O_MASK (\
> + 0x000000ff | PTRACE_O_EXITKILL | PTRACE_O_SUSPEND_SECCOMP)
>
> #include <asm/ptrace.h>
>
> diff --git a/kernel/ptrace.c b/kernel/ptrace.c
> index c8e0e05..11fa460 100644
> --- a/kernel/ptrace.c
> +++ b/kernel/ptrace.c
> @@ -556,6 +556,15 @@ static int ptrace_setoptions(struct task_struct *child, unsigned long data)
> if (data & ~(unsigned long)PTRACE_O_MASK)
> return -EINVAL;
>
> + if (unlikely(data & PTRACE_O_SUSPEND_SECCOMP)) {
> + if (!config_enabled(CONFIG_CHECKPOINT_RESTORE) ||
> + !config_enabled(CONFIG_SECCOMP))
> + return -EINVAL;
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
I tend to think that we should also require that current not be using
seccomp. Otherwise, in principle, there's a seccomp bypass for
privileged-but-seccomped programs. In any event, CRIU isn't going to
work well if you run the restorer under seccomp, since it'll start
nesting in a manner that probably isn't desirable.
> + }
> +
> /* Avoid intermediate state when all opts are cleared */
> flags = child->ptrace;
> flags &= ~(PTRACE_O_MASK << PT_OPT_FLAG_SHIFT);
> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> index 980fd26..645e42d 100644
> --- a/kernel/seccomp.c
> +++ b/kernel/seccomp.c
> @@ -590,6 +590,10 @@ void secure_computing_strict(int this_syscall)
> {
> int mode = current->seccomp.mode;
>
> + if (config_enabled(CONFIG_CHECKPOINT_RESTORE) &&
> + unlikely(current->ptrace & PT_SUSPEND_SECCOMP))
> + return;
> +
> if (mode == 0)
> return;
> else if (mode == SECCOMP_MODE_STRICT)
> @@ -691,6 +695,10 @@ u32 seccomp_phase1(struct seccomp_data *sd)
> int this_syscall = sd ? sd->nr :
> syscall_get_nr(current, task_pt_regs(current));
>
> + if (config_enabled(CONFIG_CHECKPOINT_RESTORE) &&
> + unlikely(current->ptrace & PT_SUSPEND_SECCOMP))
> + return SECCOMP_PHASE1_OK;
> +
If it's not hard, it might still be nice to try to fold this into
mode. This code is rather hot. If it would be a mess, then don't
worry about it for now.
Otherwise seems reasonable.
--Andy
Hi Andy,
On Tue, Jun 09, 2015 at 06:08:42PM -0700, Andy Lutomirski wrote:
>
> > + if (unlikely(data & PTRACE_O_SUSPEND_SECCOMP)) {
> > + if (!config_enabled(CONFIG_CHECKPOINT_RESTORE) ||
> > + !config_enabled(CONFIG_SECCOMP))
> > + return -EINVAL;
> > +
> > + if (!capable(CAP_SYS_ADMIN))
> > + return -EPERM;
>
> I tend to think that we should also require that current not be using
> seccomp. Otherwise, in principle, there's a seccomp bypass for
> privileged-but-seccomped programs. In any event, CRIU isn't going to
> work well if you run the restorer under seccomp, since it'll start
> nesting in a manner that probably isn't desirable.
Ok, I can resend with that. (sorry Oleg :)
> > + }
> > +
> > /* Avoid intermediate state when all opts are cleared */
> > flags = child->ptrace;
> > flags &= ~(PTRACE_O_MASK << PT_OPT_FLAG_SHIFT);
> > diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> > index 980fd26..645e42d 100644
> > --- a/kernel/seccomp.c
> > +++ b/kernel/seccomp.c
> > @@ -590,6 +590,10 @@ void secure_computing_strict(int this_syscall)
> > {
> > int mode = current->seccomp.mode;
> >
> > + if (config_enabled(CONFIG_CHECKPOINT_RESTORE) &&
> > + unlikely(current->ptrace & PT_SUSPEND_SECCOMP))
> > + return;
> > +
> > if (mode == 0)
> > return;
> > else if (mode == SECCOMP_MODE_STRICT)
> > @@ -691,6 +695,10 @@ u32 seccomp_phase1(struct seccomp_data *sd)
> > int this_syscall = sd ? sd->nr :
> > syscall_get_nr(current, task_pt_regs(current));
> >
> > + if (config_enabled(CONFIG_CHECKPOINT_RESTORE) &&
> > + unlikely(current->ptrace & PT_SUSPEND_SECCOMP))
> > + return SECCOMP_PHASE1_OK;
> > +
>
> If it's not hard, it might still be nice to try to fold this into
> mode. This code is rather hot. If it would be a mess, then don't
> worry about it for now.
The part I'm not immediately clear on is what to do when the tracer
dies and the task is running. Oleg pointed out that we can't play with
TIF_SECCOMP (or we could, but restoring it in this case is
complicated), and I'm not sure if playing with ->seccomp.mode has any
similar complications. I /think/ it should be ok to just re-enable it,
but I'm not sure.
I'd like to leave this patch as is (modulo the extra check) for now.
I'm still looking at a way to export mode 2 filters, so there will
hopefully be more patches in this area soon and we can reexamine then.
Thanks for the review.
Tycho
On 06/09, Andy Lutomirski wrote:
>
> On Tue, Jun 9, 2015 at 5:49 PM, Tycho Andersen
> >
> > @@ -556,6 +556,15 @@ static int ptrace_setoptions(struct task_struct *child, unsigned long data)
> > if (data & ~(unsigned long)PTRACE_O_MASK)
> > return -EINVAL;
> >
> > + if (unlikely(data & PTRACE_O_SUSPEND_SECCOMP)) {
Well, we should do this if
(data & O_SUSPEND) && !(flags & O_SUSPEND)
or at least if
(data ^ flags) & O_SUSPEND
> > + if (!config_enabled(CONFIG_CHECKPOINT_RESTORE) ||
> > + !config_enabled(CONFIG_SECCOMP))
> > + return -EINVAL;
> > +
> > + if (!capable(CAP_SYS_ADMIN))
> > + return -EPERM;
>
> I tend to think that we should also require that current not be using
> seccomp. Otherwise, in principle, there's a seccomp bypass for
> privileged-but-seccomped programs.
Andy, I simply can't understand why do we need any security check at all.
OK, yes, in theory we can have a seccomped CAP_SYS_ADMIN process, seccomp
doesn't filter ptrace, you hack that process and force it to attach to
another CAP_SYS_ADMIN/seccomped process, etc, etc... Looks too paranoid
to me.
But damn, I said many times that I won't argue ;)
> > @@ -590,6 +590,10 @@ void secure_computing_strict(int this_syscall)
> > {
> > int mode = current->seccomp.mode;
> >
> > + if (config_enabled(CONFIG_CHECKPOINT_RESTORE) &&
> > + unlikely(current->ptrace & PT_SUSPEND_SECCOMP))
> > + return;
> > +
> > if (mode == 0)
> > return;
> > else if (mode == SECCOMP_MODE_STRICT)
> > @@ -691,6 +695,10 @@ u32 seccomp_phase1(struct seccomp_data *sd)
> > int this_syscall = sd ? sd->nr :
> > syscall_get_nr(current, task_pt_regs(current));
> >
> > + if (config_enabled(CONFIG_CHECKPOINT_RESTORE) &&
> > + unlikely(current->ptrace & PT_SUSPEND_SECCOMP))
> > + return SECCOMP_PHASE1_OK;
> > +
>
> If it's not hard, it might still be nice to try to fold this into
> mode. This code is rather hot. If it would be a mess, then don't
> worry about it for now.
IMO, this would be a mess ;) At least compared to this simple patch.
Suppose we add SECCOMP_MODE_SUSPENDED. Not only this adds the problems
with detach if the tracer dies.
We need to change copy_seccomp(). And it is not clear what should we
do if the child is traced too.
We need to change prctl_set_seccomp() paths.
And even the "tracee->seccomp.mode = SECCOMP_MODE_SUSPENDED" code needs
some locking even if the tracee is stopped, we need to avoid the races
with SECCOMP_FILTER_FLAG_TSYNC from other threads.
Oleg.
On Wed, Jun 10, 2015 at 9:31 AM, Oleg Nesterov <[email protected]> wrote:
> On 06/09, Andy Lutomirski wrote:
>>
>> On Tue, Jun 9, 2015 at 5:49 PM, Tycho Andersen
>> >
>> > @@ -556,6 +556,15 @@ static int ptrace_setoptions(struct task_struct *child, unsigned long data)
>> > if (data & ~(unsigned long)PTRACE_O_MASK)
>> > return -EINVAL;
>> >
>> > + if (unlikely(data & PTRACE_O_SUSPEND_SECCOMP)) {
>
> Well, we should do this if
>
> (data & O_SUSPEND) && !(flags & O_SUSPEND)
>
> or at least if
>
> (data ^ flags) & O_SUSPEND
>
>
>> > + if (!config_enabled(CONFIG_CHECKPOINT_RESTORE) ||
>> > + !config_enabled(CONFIG_SECCOMP))
>> > + return -EINVAL;
>> > +
>> > + if (!capable(CAP_SYS_ADMIN))
>> > + return -EPERM;
>>
>> I tend to think that we should also require that current not be using
>> seccomp. Otherwise, in principle, there's a seccomp bypass for
>> privileged-but-seccomped programs.
>
> Andy, I simply can't understand why do we need any security check at all.
>
> OK, yes, in theory we can have a seccomped CAP_SYS_ADMIN process, seccomp
> doesn't filter ptrace, you hack that process and force it to attach to
> another CAP_SYS_ADMIN/seccomped process, etc, etc... Looks too paranoid
> to me.
I've sometimes considered having privileged processes I write fork and
seccomp their child. Of course, if you're allowing ptrace through
your seccomp filter, you open a giant can of worms, but I think we
should take the more paranoid approach to start and relax it later as
needed. After all, for the intended use of this patch, stuff will
break regardless of what we do if the ptracer is itself seccomped.
I could be convinced that if the ptracer is outside seccomp then we
shouldn't need the CAP_SYS_ADMIN check. That would at least make this
work in a user namespace.
>> > @@ -590,6 +590,10 @@ void secure_computing_strict(int this_syscall)
>> > {
>> > int mode = current->seccomp.mode;
>> >
>> > + if (config_enabled(CONFIG_CHECKPOINT_RESTORE) &&
>> > + unlikely(current->ptrace & PT_SUSPEND_SECCOMP))
>> > + return;
>> > +
>> > if (mode == 0)
>> > return;
>> > else if (mode == SECCOMP_MODE_STRICT)
>> > @@ -691,6 +695,10 @@ u32 seccomp_phase1(struct seccomp_data *sd)
>> > int this_syscall = sd ? sd->nr :
>> > syscall_get_nr(current, task_pt_regs(current));
>> >
>> > + if (config_enabled(CONFIG_CHECKPOINT_RESTORE) &&
>> > + unlikely(current->ptrace & PT_SUSPEND_SECCOMP))
>> > + return SECCOMP_PHASE1_OK;
>> > +
>>
>> If it's not hard, it might still be nice to try to fold this into
>> mode. This code is rather hot. If it would be a mess, then don't
>> worry about it for now.
>
> IMO, this would be a mess ;) At least compared to this simple patch.
>
> Suppose we add SECCOMP_MODE_SUSPENDED. Not only this adds the problems
> with detach if the tracer dies.
>
> We need to change copy_seccomp(). And it is not clear what should we
> do if the child is traced too.
>
> We need to change prctl_set_seccomp() paths.
>
> And even the "tracee->seccomp.mode = SECCOMP_MODE_SUSPENDED" code needs
> some locking even if the tracee is stopped, we need to avoid the races
> with SECCOMP_FILTER_FLAG_TSYNC from other threads.
>
Agreed. Let's hold off until this becomes a problem (if it ever does).
--Andy
Quoting Andy Lutomirski ([email protected]):
> On Wed, Jun 10, 2015 at 9:31 AM, Oleg Nesterov <[email protected]> wrote:
> > On 06/09, Andy Lutomirski wrote:
> >>
> >> On Tue, Jun 9, 2015 at 5:49 PM, Tycho Andersen
> >> >
> >> > @@ -556,6 +556,15 @@ static int ptrace_setoptions(struct task_struct *child, unsigned long data)
> >> > if (data & ~(unsigned long)PTRACE_O_MASK)
> >> > return -EINVAL;
> >> >
> >> > + if (unlikely(data & PTRACE_O_SUSPEND_SECCOMP)) {
> >
> > Well, we should do this if
> >
> > (data & O_SUSPEND) && !(flags & O_SUSPEND)
> >
> > or at least if
> >
> > (data ^ flags) & O_SUSPEND
> >
> >
> >> > + if (!config_enabled(CONFIG_CHECKPOINT_RESTORE) ||
> >> > + !config_enabled(CONFIG_SECCOMP))
> >> > + return -EINVAL;
> >> > +
> >> > + if (!capable(CAP_SYS_ADMIN))
> >> > + return -EPERM;
> >>
> >> I tend to think that we should also require that current not be using
> >> seccomp. Otherwise, in principle, there's a seccomp bypass for
> >> privileged-but-seccomped programs.
> >
> > Andy, I simply can't understand why do we need any security check at all.
> >
> > OK, yes, in theory we can have a seccomped CAP_SYS_ADMIN process, seccomp
> > doesn't filter ptrace, you hack that process and force it to attach to
> > another CAP_SYS_ADMIN/seccomped process, etc, etc... Looks too paranoid
> > to me.
>
> I've sometimes considered having privileged processes I write fork and
> seccomp their child. Of course, if you're allowing ptrace through
> your seccomp filter, you open a giant can of worms, but I think we
> should take the more paranoid approach to start and relax it later as
I really do intend to look at your old proposed tree for improving that...
have only done a once-over so far, though.
> needed. After all, for the intended use of this patch, stuff will
> break regardless of what we do if the ptracer is itself seccomped.
>
> I could be convinced that if the ptracer is outside seccomp then we
> shouldn't need the CAP_SYS_ADMIN check. That would at least make this
> work in a user namespace.
>
> >> > @@ -590,6 +590,10 @@ void secure_computing_strict(int this_syscall)
> >> > {
> >> > int mode = current->seccomp.mode;
> >> >
> >> > + if (config_enabled(CONFIG_CHECKPOINT_RESTORE) &&
> >> > + unlikely(current->ptrace & PT_SUSPEND_SECCOMP))
> >> > + return;
> >> > +
> >> > if (mode == 0)
> >> > return;
> >> > else if (mode == SECCOMP_MODE_STRICT)
> >> > @@ -691,6 +695,10 @@ u32 seccomp_phase1(struct seccomp_data *sd)
> >> > int this_syscall = sd ? sd->nr :
> >> > syscall_get_nr(current, task_pt_regs(current));
> >> >
> >> > + if (config_enabled(CONFIG_CHECKPOINT_RESTORE) &&
> >> > + unlikely(current->ptrace & PT_SUSPEND_SECCOMP))
> >> > + return SECCOMP_PHASE1_OK;
> >> > +
> >>
> >> If it's not hard, it might still be nice to try to fold this into
> >> mode. This code is rather hot. If it would be a mess, then don't
> >> worry about it for now.
> >
> > IMO, this would be a mess ;) At least compared to this simple patch.
> >
> > Suppose we add SECCOMP_MODE_SUSPENDED. Not only this adds the problems
> > with detach if the tracer dies.
> >
> > We need to change copy_seccomp(). And it is not clear what should we
> > do if the child is traced too.
> >
> > We need to change prctl_set_seccomp() paths.
> >
> > And even the "tracee->seccomp.mode = SECCOMP_MODE_SUSPENDED" code needs
> > some locking even if the tracee is stopped, we need to avoid the races
> > with SECCOMP_FILTER_FLAG_TSYNC from other threads.
> >
>
> Agreed. Let's hold off until this becomes a problem (if it ever does).
>
> --Andy
On Wed, Jun 10, 2015 at 10:29 AM, Serge Hallyn <[email protected]> wrote:
> Quoting Andy Lutomirski ([email protected]):
>> On Wed, Jun 10, 2015 at 9:31 AM, Oleg Nesterov <[email protected]> wrote:
>> > On 06/09, Andy Lutomirski wrote:
>> >>
>> >> On Tue, Jun 9, 2015 at 5:49 PM, Tycho Andersen
>> >> >
>> >> > @@ -556,6 +556,15 @@ static int ptrace_setoptions(struct task_struct *child, unsigned long data)
>> >> > if (data & ~(unsigned long)PTRACE_O_MASK)
>> >> > return -EINVAL;
>> >> >
>> >> > + if (unlikely(data & PTRACE_O_SUSPEND_SECCOMP)) {
>> >
>> > Well, we should do this if
>> >
>> > (data & O_SUSPEND) && !(flags & O_SUSPEND)
>> >
>> > or at least if
>> >
>> > (data ^ flags) & O_SUSPEND
>> >
>> >
>> >> > + if (!config_enabled(CONFIG_CHECKPOINT_RESTORE) ||
>> >> > + !config_enabled(CONFIG_SECCOMP))
>> >> > + return -EINVAL;
>> >> > +
>> >> > + if (!capable(CAP_SYS_ADMIN))
>> >> > + return -EPERM;
>> >>
>> >> I tend to think that we should also require that current not be using
>> >> seccomp. Otherwise, in principle, there's a seccomp bypass for
>> >> privileged-but-seccomped programs.
>> >
>> > Andy, I simply can't understand why do we need any security check at all.
>> >
>> > OK, yes, in theory we can have a seccomped CAP_SYS_ADMIN process, seccomp
>> > doesn't filter ptrace, you hack that process and force it to attach to
>> > another CAP_SYS_ADMIN/seccomped process, etc, etc... Looks too paranoid
>> > to me.
>>
>> I've sometimes considered having privileged processes I write fork and
>> seccomp their child. Of course, if you're allowing ptrace through
>> your seccomp filter, you open a giant can of worms, but I think we
>> should take the more paranoid approach to start and relax it later as
>
> I really do intend to look at your old proposed tree for improving that...
> have only done a once-over so far, though.
Don't read it yet. It's unnecessarily complicated due to the mess
that is x86's entry code, and I want to clean up the entry code first.
--Andy
On 06/10, Andy Lutomirski wrote:
>
> On Wed, Jun 10, 2015 at 9:31 AM, Oleg Nesterov <[email protected]> wrote:
> >
> > Andy, I simply can't understand why do we need any security check at all.
...
> I think we
> should take the more paranoid approach to start and relax it later as
> needed.
OK. I didn't really tried to argue. I actually replied to other part
of you email, and simply could not resist ;)
Oleg.
On Wed, Jun 10, 2015 at 10:20 AM, Andy Lutomirski <[email protected]> wrote:
> On Wed, Jun 10, 2015 at 9:31 AM, Oleg Nesterov <[email protected]> wrote:
>> On 06/09, Andy Lutomirski wrote:
>>>
>>> On Tue, Jun 9, 2015 at 5:49 PM, Tycho Andersen
>>> >
>>> > @@ -556,6 +556,15 @@ static int ptrace_setoptions(struct task_struct *child, unsigned long data)
>>> > if (data & ~(unsigned long)PTRACE_O_MASK)
>>> > return -EINVAL;
>>> >
>>> > + if (unlikely(data & PTRACE_O_SUSPEND_SECCOMP)) {
>>
>> Well, we should do this if
>>
>> (data & O_SUSPEND) && !(flags & O_SUSPEND)
>>
>> or at least if
>>
>> (data ^ flags) & O_SUSPEND
>>
>>
>>> > + if (!config_enabled(CONFIG_CHECKPOINT_RESTORE) ||
>>> > + !config_enabled(CONFIG_SECCOMP))
>>> > + return -EINVAL;
>>> > +
>>> > + if (!capable(CAP_SYS_ADMIN))
>>> > + return -EPERM;
>>>
>>> I tend to think that we should also require that current not be using
>>> seccomp. Otherwise, in principle, there's a seccomp bypass for
>>> privileged-but-seccomped programs.
>>
>> Andy, I simply can't understand why do we need any security check at all.
>>
>> OK, yes, in theory we can have a seccomped CAP_SYS_ADMIN process, seccomp
>> doesn't filter ptrace, you hack that process and force it to attach to
>> another CAP_SYS_ADMIN/seccomped process, etc, etc... Looks too paranoid
>> to me.
>
> I've sometimes considered having privileged processes I write fork and
> seccomp their child. Of course, if you're allowing ptrace through
> your seccomp filter, you open a giant can of worms, but I think we
> should take the more paranoid approach to start and relax it later as
> needed. After all, for the intended use of this patch, stuff will
> break regardless of what we do if the ptracer is itself seccomped.
>
> I could be convinced that if the ptracer is outside seccomp then we
> shouldn't need the CAP_SYS_ADMIN check. That would at least make this
> work in a user namespace.
But not if that namespace is running under a manager that has added a
seccomp filter to do things like drop finit_module, as lxc does.
Let's start with CAP_SYS_ADMIN, and when we have an actual use-case,
we can change it then.
>
>>> > @@ -590,6 +590,10 @@ void secure_computing_strict(int this_syscall)
>>> > {
>>> > int mode = current->seccomp.mode;
>>> >
>>> > + if (config_enabled(CONFIG_CHECKPOINT_RESTORE) &&
>>> > + unlikely(current->ptrace & PT_SUSPEND_SECCOMP))
>>> > + return;
>>> > +
>>> > if (mode == 0)
>>> > return;
>>> > else if (mode == SECCOMP_MODE_STRICT)
>>> > @@ -691,6 +695,10 @@ u32 seccomp_phase1(struct seccomp_data *sd)
>>> > int this_syscall = sd ? sd->nr :
>>> > syscall_get_nr(current, task_pt_regs(current));
>>> >
>>> > + if (config_enabled(CONFIG_CHECKPOINT_RESTORE) &&
>>> > + unlikely(current->ptrace & PT_SUSPEND_SECCOMP))
>>> > + return SECCOMP_PHASE1_OK;
>>> > +
>>>
>>> If it's not hard, it might still be nice to try to fold this into
>>> mode. This code is rather hot. If it would be a mess, then don't
>>> worry about it for now.
>>
>> IMO, this would be a mess ;) At least compared to this simple patch.
>>
>> Suppose we add SECCOMP_MODE_SUSPENDED. Not only this adds the problems
>> with detach if the tracer dies.
>>
>> We need to change copy_seccomp(). And it is not clear what should we
>> do if the child is traced too.
>>
>> We need to change prctl_set_seccomp() paths.
>>
>> And even the "tracee->seccomp.mode = SECCOMP_MODE_SUSPENDED" code needs
>> some locking even if the tracee is stopped, we need to avoid the races
>> with SECCOMP_FILTER_FLAG_TSYNC from other threads.
>>
>
> Agreed. Let's hold off until this becomes a problem (if it ever does).
Arg, right, no. I don't want this represented in seccomp.mode. Way too
much would get touched for little benefit.
Thanks! And sorry Tycho as we all disagree about how to disagree with
your patch... :)
--
Kees Cook
Chrome OS Security
On 06/10, Kees Cook wrote:
>
> And sorry Tycho as we all disagree about how to disagree with
> your patch... :)
Yes ;)
So, just in case, I am fine with this version.
Andy wants another security check, OK, this is fine too to me.
Oleg.
On Tue, Jun 9, 2015 at 5:49 PM, Tycho Andersen
<[email protected]> wrote:
> This patch is the first step in enabling checkpoint/restore of processes
> with seccomp enabled.
>
> One of the things CRIU does while dumping tasks is inject code into them
> via ptrace to collect information that is only available to the process
> itself. However, if we are in a seccomp mode where these processes are
> prohibited from making these syscalls, then what CRIU does kills the task.
>
> This patch adds a new ptrace option, PTRACE_O_SUSPEND_SECCOMP, that enables
> a task from the init user namespace which has CAP_SYS_ADMIN and no seccomp
> filters to disable (and re-enable) seccomp filters for another task so that
> they can be successfully dumped (and restored). We restrict the set of
> processes that can disable seccomp through ptrace because although today
> ptrace can be used to bypass seccomp, there is some discussion of closing
> this loophole in the future and we would like this patch to not depend on
> that behavior and be future proofed for when it is removed.
>
> Note that seccomp can be suspended before any filters are actually
> installed; this behavior is useful on criu restore, so that we can suspend
> seccomp, restore the filters, unmap our restore code from the restored
> process' address space, and then resume the task by detaching and have the
> filters resumed as well.
>
> v2 changes:
>
> * require that the tracer have no seccomp filters installed
> * drop TIF_NOTSC manipulation from the patch
> * change from ptrace command to a ptrace option and use this ptrace option
> as the flag to check. This means that as soon as the tracer
> detaches/dies, seccomp is re-enabled and as a corrollary that one can not
> disable seccomp across PTRACE_ATTACHs.
>
> v3 changes:
>
> * get rid of various #ifdefs everywhere
> * report more sensible errors when PTRACE_O_SUSPEND_SECCOMP is incorrectly
> used
>
> v4 changes:
>
> * get rid of may_suspend_seccomp() in favor of a capable() check in ptrace
> directly
>
> Signed-off-by: Tycho Andersen <[email protected]>
> CC: Kees Cook <[email protected]>
> CC: Andy Lutomirski <[email protected]>
> CC: Will Drewry <[email protected]>
> CC: Roland McGrath <[email protected]>
> CC: Oleg Nesterov <[email protected]>
> CC: Pavel Emelyanov <[email protected]>
> CC: Serge E. Hallyn <[email protected]>
> ---
> include/linux/ptrace.h | 1 +
> include/uapi/linux/ptrace.h | 6 ++++--
> kernel/ptrace.c | 9 +++++++++
> kernel/seccomp.c | 8 ++++++++
> 4 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/ptrace.h b/include/linux/ptrace.h
> index 987a73a..061265f 100644
> --- a/include/linux/ptrace.h
> +++ b/include/linux/ptrace.h
> @@ -34,6 +34,7 @@
> #define PT_TRACE_SECCOMP PT_EVENT_FLAG(PTRACE_EVENT_SECCOMP)
>
> #define PT_EXITKILL (PTRACE_O_EXITKILL << PT_OPT_FLAG_SHIFT)
> +#define PT_SUSPEND_SECCOMP (PTRACE_O_SUSPEND_SECCOMP << PT_OPT_FLAG_SHIFT)
>
> /* single stepping state bits (used on ARM and PA-RISC) */
> #define PT_SINGLESTEP_BIT 31
> diff --git a/include/uapi/linux/ptrace.h b/include/uapi/linux/ptrace.h
> index cf1019e..a7a6979 100644
> --- a/include/uapi/linux/ptrace.h
> +++ b/include/uapi/linux/ptrace.h
> @@ -89,9 +89,11 @@ struct ptrace_peeksiginfo_args {
> #define PTRACE_O_TRACESECCOMP (1 << PTRACE_EVENT_SECCOMP)
>
> /* eventless options */
> -#define PTRACE_O_EXITKILL (1 << 20)
> +#define PTRACE_O_EXITKILL (1 << 20)
> +#define PTRACE_O_SUSPEND_SECCOMP (1 << 21)
>
> -#define PTRACE_O_MASK (0x000000ff | PTRACE_O_EXITKILL)
> +#define PTRACE_O_MASK (\
> + 0x000000ff | PTRACE_O_EXITKILL | PTRACE_O_SUSPEND_SECCOMP)
>
> #include <asm/ptrace.h>
>
> diff --git a/kernel/ptrace.c b/kernel/ptrace.c
> index c8e0e05..11fa460 100644
> --- a/kernel/ptrace.c
> +++ b/kernel/ptrace.c
> @@ -556,6 +556,15 @@ static int ptrace_setoptions(struct task_struct *child, unsigned long data)
> if (data & ~(unsigned long)PTRACE_O_MASK)
> return -EINVAL;
>
> + if (unlikely(data & PTRACE_O_SUSPEND_SECCOMP)) {
> + if (!config_enabled(CONFIG_CHECKPOINT_RESTORE) ||
> + !config_enabled(CONFIG_SECCOMP))
> + return -EINVAL;
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
> + }
> +
> /* Avoid intermediate state when all opts are cleared */
> flags = child->ptrace;
> flags &= ~(PTRACE_O_MASK << PT_OPT_FLAG_SHIFT);
> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> index 980fd26..645e42d 100644
> --- a/kernel/seccomp.c
> +++ b/kernel/seccomp.c
> @@ -590,6 +590,10 @@ void secure_computing_strict(int this_syscall)
> {
> int mode = current->seccomp.mode;
>
> + if (config_enabled(CONFIG_CHECKPOINT_RESTORE) &&
> + unlikely(current->ptrace & PT_SUSPEND_SECCOMP))
> + return;
> +
> if (mode == 0)
> return;
> else if (mode == SECCOMP_MODE_STRICT)
> @@ -691,6 +695,10 @@ u32 seccomp_phase1(struct seccomp_data *sd)
> int this_syscall = sd ? sd->nr :
> syscall_get_nr(current, task_pt_regs(current));
>
> + if (config_enabled(CONFIG_CHECKPOINT_RESTORE) &&
> + unlikely(current->ptrace & PT_SUSPEND_SECCOMP))
> + return SECCOMP_PHASE1_OK;
> +
> switch (mode) {
> case SECCOMP_MODE_STRICT:
> __secure_computing_strict(this_syscall); /* may call do_exit */
> --
> 2.1.4
>
And if I've convinced Andy to be okay with this patch, consider v4:
Acked-by: Kees Cook <[email protected]>
-Kees
--
Kees Cook
Chrome OS Security
On Wed, Jun 10, 2015 at 01:33:21PM -0700, Kees Cook wrote:
>
> And if I've convinced Andy to be okay with this patch, consider v4:
>
> Acked-by: Kees Cook <[email protected]>
Thanks, I'm happy to send a v5 with checking seccomp (and
->ptrace & PT_SUSPEND_SECCOMP) if you'd feel better with that, Andy.
Tycho
On Wed, Jun 10, 2015 at 1:18 PM, Kees Cook <[email protected]> wrote:
> On Wed, Jun 10, 2015 at 10:20 AM, Andy Lutomirski <[email protected]> wrote:
>> On Wed, Jun 10, 2015 at 9:31 AM, Oleg Nesterov <[email protected]> wrote:
>>> On 06/09, Andy Lutomirski wrote:
>>>>
>>>> On Tue, Jun 9, 2015 at 5:49 PM, Tycho Andersen
>>>> >
>>>> > @@ -556,6 +556,15 @@ static int ptrace_setoptions(struct task_struct *child, unsigned long data)
>>>> > if (data & ~(unsigned long)PTRACE_O_MASK)
>>>> > return -EINVAL;
>>>> >
>>>> > + if (unlikely(data & PTRACE_O_SUSPEND_SECCOMP)) {
>>>
>>> Well, we should do this if
>>>
>>> (data & O_SUSPEND) && !(flags & O_SUSPEND)
>>>
>>> or at least if
>>>
>>> (data ^ flags) & O_SUSPEND
>>>
>>>
>>>> > + if (!config_enabled(CONFIG_CHECKPOINT_RESTORE) ||
>>>> > + !config_enabled(CONFIG_SECCOMP))
>>>> > + return -EINVAL;
>>>> > +
>>>> > + if (!capable(CAP_SYS_ADMIN))
>>>> > + return -EPERM;
>>>>
>>>> I tend to think that we should also require that current not be using
>>>> seccomp. Otherwise, in principle, there's a seccomp bypass for
>>>> privileged-but-seccomped programs.
>>>
>>> Andy, I simply can't understand why do we need any security check at all.
>>>
>>> OK, yes, in theory we can have a seccomped CAP_SYS_ADMIN process, seccomp
>>> doesn't filter ptrace, you hack that process and force it to attach to
>>> another CAP_SYS_ADMIN/seccomped process, etc, etc... Looks too paranoid
>>> to me.
>>
>> I've sometimes considered having privileged processes I write fork and
>> seccomp their child. Of course, if you're allowing ptrace through
>> your seccomp filter, you open a giant can of worms, but I think we
>> should take the more paranoid approach to start and relax it later as
>> needed. After all, for the intended use of this patch, stuff will
>> break regardless of what we do if the ptracer is itself seccomped.
>>
>> I could be convinced that if the ptracer is outside seccomp then we
>> shouldn't need the CAP_SYS_ADMIN check. That would at least make this
>> work in a user namespace.
>
> But not if that namespace is running under a manager that has added a
> seccomp filter to do things like drop finit_module, as lxc does.
In that case, criu isn't going to handle seccomp right regardless of
what our security check is, so I think we can safely deal with the
security aspects of that case once we figure out the functionality
part.
IOW, I think I still like the direct "you must not be seccomped in
order to suspend seccomp" rule.
--Andy
On Fri, Jun 12, 2015 at 4:27 PM, Andy Lutomirski <[email protected]> wrote:
> On Wed, Jun 10, 2015 at 1:18 PM, Kees Cook <[email protected]> wrote:
>> On Wed, Jun 10, 2015 at 10:20 AM, Andy Lutomirski <[email protected]> wrote:
>>> On Wed, Jun 10, 2015 at 9:31 AM, Oleg Nesterov <[email protected]> wrote:
>>>> On 06/09, Andy Lutomirski wrote:
>>>>>
>>>>> On Tue, Jun 9, 2015 at 5:49 PM, Tycho Andersen
>>>>> >
>>>>> > @@ -556,6 +556,15 @@ static int ptrace_setoptions(struct task_struct *child, unsigned long data)
>>>>> > if (data & ~(unsigned long)PTRACE_O_MASK)
>>>>> > return -EINVAL;
>>>>> >
>>>>> > + if (unlikely(data & PTRACE_O_SUSPEND_SECCOMP)) {
>>>>
>>>> Well, we should do this if
>>>>
>>>> (data & O_SUSPEND) && !(flags & O_SUSPEND)
>>>>
>>>> or at least if
>>>>
>>>> (data ^ flags) & O_SUSPEND
>>>>
>>>>
>>>>> > + if (!config_enabled(CONFIG_CHECKPOINT_RESTORE) ||
>>>>> > + !config_enabled(CONFIG_SECCOMP))
>>>>> > + return -EINVAL;
>>>>> > +
>>>>> > + if (!capable(CAP_SYS_ADMIN))
>>>>> > + return -EPERM;
>>>>>
>>>>> I tend to think that we should also require that current not be using
>>>>> seccomp. Otherwise, in principle, there's a seccomp bypass for
>>>>> privileged-but-seccomped programs.
>>>>
>>>> Andy, I simply can't understand why do we need any security check at all.
>>>>
>>>> OK, yes, in theory we can have a seccomped CAP_SYS_ADMIN process, seccomp
>>>> doesn't filter ptrace, you hack that process and force it to attach to
>>>> another CAP_SYS_ADMIN/seccomped process, etc, etc... Looks too paranoid
>>>> to me.
>>>
>>> I've sometimes considered having privileged processes I write fork and
>>> seccomp their child. Of course, if you're allowing ptrace through
>>> your seccomp filter, you open a giant can of worms, but I think we
>>> should take the more paranoid approach to start and relax it later as
>>> needed. After all, for the intended use of this patch, stuff will
>>> break regardless of what we do if the ptracer is itself seccomped.
>>>
>>> I could be convinced that if the ptracer is outside seccomp then we
>>> shouldn't need the CAP_SYS_ADMIN check. That would at least make this
>>> work in a user namespace.
>>
>> But not if that namespace is running under a manager that has added a
>> seccomp filter to do things like drop finit_module, as lxc does.
>
> In that case, criu isn't going to handle seccomp right regardless of
> what our security check is, so I think we can safely deal with the
> security aspects of that case once we figure out the functionality
> part.
>
> IOW, I think I still like the direct "you must not be seccomped in
> order to suspend seccomp" rule.
Adding that restriction would be fine by me.
-Kees
--
Kees Cook
Chrome OS Security
On Fri, Jun 12, 2015 at 04:29:00PM -0700, Kees Cook wrote:
> On Fri, Jun 12, 2015 at 4:27 PM, Andy Lutomirski <[email protected]> wrote:
> > On Wed, Jun 10, 2015 at 1:18 PM, Kees Cook <[email protected]> wrote:
> >> On Wed, Jun 10, 2015 at 10:20 AM, Andy Lutomirski <[email protected]> wrote:
> >>> On Wed, Jun 10, 2015 at 9:31 AM, Oleg Nesterov <[email protected]> wrote:
> >>>> On 06/09, Andy Lutomirski wrote:
> >>>>>
> >>>>> On Tue, Jun 9, 2015 at 5:49 PM, Tycho Andersen
> >>>>> >
> >>>>> > @@ -556,6 +556,15 @@ static int ptrace_setoptions(struct task_struct *child, unsigned long data)
> >>>>> > if (data & ~(unsigned long)PTRACE_O_MASK)
> >>>>> > return -EINVAL;
> >>>>> >
> >>>>> > + if (unlikely(data & PTRACE_O_SUSPEND_SECCOMP)) {
> >>>>
> >>>> Well, we should do this if
> >>>>
> >>>> (data & O_SUSPEND) && !(flags & O_SUSPEND)
> >>>>
> >>>> or at least if
> >>>>
> >>>> (data ^ flags) & O_SUSPEND
> >>>>
> >>>>
> >>>>> > + if (!config_enabled(CONFIG_CHECKPOINT_RESTORE) ||
> >>>>> > + !config_enabled(CONFIG_SECCOMP))
> >>>>> > + return -EINVAL;
> >>>>> > +
> >>>>> > + if (!capable(CAP_SYS_ADMIN))
> >>>>> > + return -EPERM;
> >>>>>
> >>>>> I tend to think that we should also require that current not be using
> >>>>> seccomp. Otherwise, in principle, there's a seccomp bypass for
> >>>>> privileged-but-seccomped programs.
> >>>>
> >>>> Andy, I simply can't understand why do we need any security check at all.
> >>>>
> >>>> OK, yes, in theory we can have a seccomped CAP_SYS_ADMIN process, seccomp
> >>>> doesn't filter ptrace, you hack that process and force it to attach to
> >>>> another CAP_SYS_ADMIN/seccomped process, etc, etc... Looks too paranoid
> >>>> to me.
> >>>
> >>> I've sometimes considered having privileged processes I write fork and
> >>> seccomp their child. Of course, if you're allowing ptrace through
> >>> your seccomp filter, you open a giant can of worms, but I think we
> >>> should take the more paranoid approach to start and relax it later as
> >>> needed. After all, for the intended use of this patch, stuff will
> >>> break regardless of what we do if the ptracer is itself seccomped.
> >>>
> >>> I could be convinced that if the ptracer is outside seccomp then we
> >>> shouldn't need the CAP_SYS_ADMIN check. That would at least make this
> >>> work in a user namespace.
> >>
> >> But not if that namespace is running under a manager that has added a
> >> seccomp filter to do things like drop finit_module, as lxc does.
> >
> > In that case, criu isn't going to handle seccomp right regardless of
> > what our security check is, so I think we can safely deal with the
> > security aspects of that case once we figure out the functionality
> > part.
> >
> > IOW, I think I still like the direct "you must not be seccomped in
> > order to suspend seccomp" rule.
>
> Adding that restriction would be fine by me.
Ok, I just sent v5 with this change. I didn't carry your ack in the
hopes that I could get you to take this patch in the seccomp tree. Let
me know if that's not the right thing to do.
Thanks,
Tycho