[PATCH RESEND 0/2] seccomp: Allow using `SECCOMP_MODE_STRICT` with `SECCOMP_MODE_FILTER`

[PATCH RESEND 0/2] seccomp: Allow using `SECCOMP_MODE_STRICT` with `SECCOMP_MODE_FILTER`

[Jamie Hill-Daniel]

This patch adjusts the logic used by seccomp to allow applying both
`SECCOMP_MODE_FILTER` and `SECCOMP_MODE_STRICT` to the same process.

Currently, once seccomp has been initialized, a process may not
transition to a different mode (only add additional filters).
This means that in container environments such as Docker, which by
default runs with `SECCOMP_MODE_FILTER`, processes may not enable
`SECCOMP_MODE_STRICT`. This is an obstacle to using applications
requiring `SECCOMP_MODE_STRICT` in these environments, and requires
disabling these security measures.

This patch introduces a new `SECCOMP_MODE_COMBINED` (used internally,
not exposed to userspace). When a process attempts to apply
`SECCOMP_MODE_FILTER` or `SECCOMP_MODE_STRICT`, this mode will be used
instead if the other mode is already enabled.

When subsequently running secure computing checks, we run the strict
checks followed by any installed filters.

Link: https://github.com/moby/moby/issues/42082

Signed-off-by: Jamie Hill-Daniel <jamie@hill-daniel.co.uk>
---
Jamie Hill-Daniel (2):
      seccomp: Allow using `SECCOMP_MODE_STRICT` with `SECCOMP_MODE_FILTER`
      selftest: seccomp: Adjust test for using both `STRICT` and `FILTER`

 kernel/seccomp.c                              | 46 +++++++++++++++------------
 tools/testing/selftests/seccomp/seccomp_bpf.c |  5 ++-
 2 files changed, 28 insertions(+), 23 deletions(-)
---
base-commit: 7d0a66e4bb9081d75c82ec4957c50034cb0ea449
change-id: 20260302-seccomp-combined-24bc3dbe32fd

Best regards,
-- 
Jamie Hill-Daniel <jamie@hill-daniel.co.uk>

[PATCH RESEND 1/2] seccomp: Allow using `SECCOMP_MODE_STRICT` with `SECCOMP_MODE_FILTER`

[Jamie Hill-Daniel]

It is currently impossible to enable `SECCOMP_MODE_STRICT` if
`SECCOMP_MODE_FILTER` is enabled, and vice-versa. This makes using
seccomp difficult in environments such as Docker, which installs a
seccomp filter by default.

Introduce a new internal `SECCOMP_MODE_COMBINED`
that runs `strict` checks, followed by any installed filters.

Link: https://github.com/moby/moby/issues/42082
Signed-off-by: Jamie Hill-Daniel <jamie@hill-daniel.co.uk>
---
 kernel/seccomp.c | 46 ++++++++++++++++++++++++++--------------------
 1 file changed, 26 insertions(+), 20 deletions(-)

diff --git a/kernel/seccomp.c b/kernel/seccomp.c
index 25f62867a16d..8201a050d358 100644
--- a/kernel/seccomp.c
+++ b/kernel/seccomp.c
@@ -33,6 +33,8 @@
 
 /* Not exposed in headers: strictly internal use only. */
 #define SECCOMP_MODE_DEAD	(SECCOMP_MODE_FILTER + 1)
+/* Run SECCOMP_MODE_STRICT checks, followed by SECCOMP_MODE_FILTER  */
+#define SECCOMP_MODE_COMBINED (SECCOMP_MODE_DEAD + 1)
 
 #ifdef CONFIG_SECCOMP_FILTER
 #include <linux/file.h>
@@ -432,14 +434,21 @@ static u32 seccomp_run_filters(const struct seccomp_data *sd,
 }
 #endif /* CONFIG_SECCOMP_FILTER */
 
-static inline bool seccomp_may_assign_mode(unsigned long seccomp_mode)
+/**
+ * seccomp_needs_combined: internal function for checking if requested mode
+ * needs to be upgraded to `SECCOMP_MODE_COMBINED`.
+ *
+ */
+static inline bool seccomp_needs_combined(unsigned long seccomp_mode)
 {
 	assert_spin_locked(&current->sighand->siglock);
 
-	if (current->seccomp.mode && current->seccomp.mode != seccomp_mode)
-		return false;
+	if ((current->seccomp.mode == SECCOMP_MODE_STRICT ||
+	     current->seccomp.mode == SECCOMP_MODE_FILTER) &&
+	    current->seccomp.mode != seccomp_mode)
+		return true;
 
-	return true;
+	return false;
 }
 
 void __weak arch_seccomp_spec_mitigate(struct task_struct *task) { }
@@ -1407,6 +1416,9 @@ int __secure_computing(void)
 		WARN_ON_ONCE(1);
 		do_exit(SIGKILL);
 		return -1;
+	case SECCOMP_MODE_COMBINED:
+		__secure_computing_strict(this_syscall);
+		return __seccomp_filter(this_syscall, false);
 	default:
 		BUG();
 	}
@@ -1421,30 +1433,23 @@ long prctl_get_seccomp(void)
 /**
  * seccomp_set_mode_strict: internal function for setting strict seccomp
  *
- * Once current->seccomp.mode is non-zero, it may not be changed.
+ * Once current->seccomp.mode is non-zero, it may only be changed to `COMBINED` or `DEAD`.
  *
- * Returns 0 on success or -EINVAL on failure.
  */
-static long seccomp_set_mode_strict(void)
+static void seccomp_set_mode_strict(void)
 {
-	const unsigned long seccomp_mode = SECCOMP_MODE_STRICT;
-	long ret = -EINVAL;
+	unsigned long seccomp_mode = SECCOMP_MODE_STRICT;
 
 	spin_lock_irq(&current->sighand->siglock);
 
-	if (!seccomp_may_assign_mode(seccomp_mode))
-		goto out;
+	if (seccomp_needs_combined(seccomp_mode))
+		seccomp_mode = SECCOMP_MODE_COMBINED;
 
 #ifdef TIF_NOTSC
 	disable_TSC();
 #endif
 	seccomp_assign_mode(current, seccomp_mode, 0);
-	ret = 0;
-
-out:
 	spin_unlock_irq(&current->sighand->siglock);
-
-	return ret;
 }
 
 #ifdef CONFIG_SECCOMP_FILTER
@@ -1956,7 +1961,7 @@ static bool has_duplicate_listener(struct seccomp_filter *new_child)
 static long seccomp_set_mode_filter(unsigned int flags,
 				    const char __user *filter)
 {
-	const unsigned long seccomp_mode = SECCOMP_MODE_FILTER;
+	long seccomp_mode = SECCOMP_MODE_FILTER;
 	struct seccomp_filter *prepared = NULL;
 	long ret = -EINVAL;
 	int listener = -1;
@@ -2016,8 +2021,8 @@ static long seccomp_set_mode_filter(unsigned int flags,
 
 	spin_lock_irq(&current->sighand->siglock);
 
-	if (!seccomp_may_assign_mode(seccomp_mode))
-		goto out;
+	if (seccomp_needs_combined(seccomp_mode))
+		seccomp_mode = SECCOMP_MODE_COMBINED;
 
 	if (has_duplicate_listener(prepared)) {
 		ret = -EBUSY;
@@ -2105,7 +2110,8 @@ static long do_seccomp(unsigned int op, unsigned int flags,
 	case SECCOMP_SET_MODE_STRICT:
 		if (flags != 0 || uargs != NULL)
 			return -EINVAL;
-		return seccomp_set_mode_strict();
+		seccomp_set_mode_strict();
+		return 0;
 	case SECCOMP_SET_MODE_FILTER:
 		return seccomp_set_mode_filter(flags, uargs);
 	case SECCOMP_GET_ACTION_AVAIL:

-- 
2.54.0

Re: [PATCH RESEND 1/2] seccomp: Allow using `SECCOMP_MODE_STRICT` with `SECCOMP_MODE_FILTER`

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] SECCOMP_MODE_COMBINED allows a ptracer to completely bypass strict mode restrictions via system call manipulation.
- [High] The internal SECCOMP_MODE_COMBINED constant is leaked to userspace, violating ABI stability.
- [High] Checkpoint/Restore (CRIU) and Ptrace filter dumping are broken for processes in COMBINED mode.
- [High] Thread synchronization (TSYNC) is broken and causes state inconsistencies for processes in COMBINED mode.
- [Medium] The transition from SECCOMP_MODE_STRICT to SECCOMP_MODE_COMBINED is structurally unreachable.
--

commit c1df2665317e85f0cd779f5b52a0ed4763185a42
Author: Jamie Hill-Daniel <clubby789@gmail.com>

seccomp: Allow using SECCOMP_MODE_STRICT with SECCOMP_MODE_FILTER

It is currently impossible to enable SECCOMP_MODE_STRICT if
SECCOMP_MODE_FILTER is enabled, and vice-versa. This makes using
seccomp difficult in environments such as Docker, which installs a
seccomp filter by default.

Introduce a new internal SECCOMP_MODE_COMBINED
that runs strict checks, followed by any installed filters.

Link: https://github.com/moby/moby/issues/42082

> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> index 25f62867a16d9..8201a050d358f 100644
> --- a/kernel/seccomp.c
> +++ b/kernel/seccomp.c
> @@ -33,6 +33,8 @@
>  
>  /* Not exposed in headers: strictly internal use only. */
>  #define SECCOMP_MODE_DEAD	(SECCOMP_MODE_FILTER + 1)
> +/* Run SECCOMP_MODE_STRICT checks, followed by SECCOMP_MODE_FILTER  */
> +#define SECCOMP_MODE_COMBINED (SECCOMP_MODE_DEAD + 1)

[Severity: High]
Does this new internal mode leak to userspace and break ABI expectations?

Looking at prctl_get_seccomp(), it returns current->seccomp.mode directly.
This will now return 4 to userspace for tasks in combined mode, but userspace
utilities like systemd and container runtimes strictly expect the mode to be
0 (DISABLED), 1 (STRICT), or 2 (FILTER).

[Severity: High]
Will setting current->seccomp.mode to SECCOMP_MODE_COMBINED break thread
synchronization (TSYNC)?

seccomp_can_sync_threads() validates sibling threads and only allows
synchronization if they are in SECCOMP_MODE_DISABLED or
SECCOMP_MODE_FILTER. If any thread is in SECCOMP_MODE_COMBINED, this
validation unconditionally fails and SECCOMP_FILTER_FLAG_TSYNC operations
abort with -ESRCH.

[Severity: High]
Can this new mode prevent checkpoint/restore (CRIU) and ptrace filter
dumping?

get_nth_filter(), which is the backend for PTRACE_SECCOMP_GET_FILTER and
seccomp metadata inspection, explicitly enforces the condition:

    if (task->seccomp.mode != SECCOMP_MODE_FILTER)
        return ERR_PTR(-EINVAL);

When a process runs in SECCOMP_MODE_COMBINED, this validation will fail,
making it impossible to inspect, dump, or checkpoint the attached seccomp
BPF filters.

[ ... ]

> @@ -432,14 +434,21 @@ static u32 seccomp_run_filters(const struct seccomp_data *sd,
>  }
>  #endif /* CONFIG_SECCOMP_FILTER */
>  
> -static inline bool seccomp_may_assign_mode(unsigned long seccomp_mode)
> +/**
> + * seccomp_needs_combined: internal function for checking if requested mode
> + * needs to be upgraded to SECCOMP_MODE_COMBINED.
> + *
> + */
> +static inline bool seccomp_needs_combined(unsigned long seccomp_mode)
>  {
>  	assert_spin_locked(&current->sighand->siglock);
>  
> -	if (current->seccomp.mode && current->seccomp.mode != seccomp_mode)
> -		return false;
> +	if ((current->seccomp.mode == SECCOMP_MODE_STRICT ||
> +	     current->seccomp.mode == SECCOMP_MODE_FILTER) &&
> +	    current->seccomp.mode != seccomp_mode)
> +		return true;

[Severity: Medium]
Is the transition from SECCOMP_MODE_STRICT to SECCOMP_MODE_COMBINED
structurally unreachable?

In strict mode, the __secure_computing_strict() hook runs during syscall
entry and unconditionally kills the process via SIGKILL if it attempts to
execute any syscall other than read, write, _exit, or sigreturn.

Any attempt to invoke prctl or seccomp to install a filter while in
strict mode will result in immediate termination, preventing the upgrade.

> -	return true;
> +	return false;
>  }

[ ... ]

> @@ -1407,6 +1416,9 @@ int __secure_computing(void)
>  		WARN_ON_ONCE(1);
>  		do_exit(SIGKILL);
>  		return -1;
> +	case SECCOMP_MODE_COMBINED:
> +		__secure_computing_strict(this_syscall);
> +		return __seccomp_filter(this_syscall, false);

[Severity: High]
Could this sequence allow a ptracer to completely bypass strict mode
restrictions via system call manipulation?

If the original system call is permitted by the strict check (for example,
read), __secure_computing_strict() passes and __seccomp_filter()
evaluates the BPF filter.

If the filter returns SECCOMP_RET_TRACE, a ptracer is notified and can use
PTRACE_SETREGS to modify the system call number (for example, changing it
to execve).

While __seccomp_filter() correctly re-evaluates the newly injected syscall
against the BPF filter, __secure_computing_strict() is never re-run. If
the filter permits the new syscall, it will execute, allowing the ptracer to
completely bypass the strict mode sandbox.

>  	default:
>  		BUG();
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260526-seccomp-combined-v1-0-304b1cc3ad24@hill-daniel.co.uk?part=1

Re: [PATCH RESEND 1/2] seccomp: Allow using `SECCOMP_MODE_STRICT` with `SECCOMP_MODE_FILTER`

[Will Drewry]

On Tue, May 26, 2026 at 10:42 AM Jamie Hill-Daniel <clubby789@gmail.com> wrote:
>
> It is currently impossible to enable `SECCOMP_MODE_STRICT` if
> `SECCOMP_MODE_FILTER` is enabled, and vice-versa. This makes using
> seccomp difficult in environments such as Docker, which installs a
> seccomp filter by default.

Some quick thoughts on your resend -- the original reasons for
this approach:
(a) filter policy != strict policy
(b) filter can implement strict, if layering is desired
(c) minimize checks in the syscall entry/return path

I'd expected folks to simply create the ~80 byte strict filter and install
it if they needed STRICT policy. More discussion below.

> Introduce a new internal `SECCOMP_MODE_COMBINED`
> that runs `strict` checks, followed by any installed filters.
>
> Link: https://github.com/moby/moby/issues/42082
> Signed-off-by: Jamie Hill-Daniel <jamie@hill-daniel.co.uk>
> ---
>  kernel/seccomp.c | 46 ++++++++++++++++++++++++++--------------------
>  1 file changed, 26 insertions(+), 20 deletions(-)
>
> diff --git a/kernel/seccomp.c b/kernel/seccomp.c
> index 25f62867a16d..8201a050d358 100644
> --- a/kernel/seccomp.c
> +++ b/kernel/seccomp.c
> @@ -33,6 +33,8 @@
>
>  /* Not exposed in headers: strictly internal use only. */
>  #define SECCOMP_MODE_DEAD      (SECCOMP_MODE_FILTER + 1)
> +/* Run SECCOMP_MODE_STRICT checks, followed by SECCOMP_MODE_FILTER  */
> +#define SECCOMP_MODE_COMBINED (SECCOMP_MODE_DEAD + 1)

I'm not sure if DEAD is meant to be fixed at the end of all modes or
not -- given that it's internal.

>
>  #ifdef CONFIG_SECCOMP_FILTER
>  #include <linux/file.h>
> @@ -432,14 +434,21 @@ static u32 seccomp_run_filters(const struct seccomp_data *sd,
>  }
>  #endif /* CONFIG_SECCOMP_FILTER */
>
> -static inline bool seccomp_may_assign_mode(unsigned long seccomp_mode)
> +/**
> + * seccomp_needs_combined: internal function for checking if requested mode
> + * needs to be upgraded to `SECCOMP_MODE_COMBINED`.
> + *
> + */
> +static inline bool seccomp_needs_combined(unsigned long seccomp_mode)

It is easier to reason about if you keep the access checks separate from the
behavior-change decision. Setting seccomp modes isn't on a particularly
performance-critical path, so we can be more verbose and explicit.

>  {
>         assert_spin_locked(&current->sighand->siglock);
>
> -       if (current->seccomp.mode && current->seccomp.mode != seccomp_mode)
> -               return false;
> +       if ((current->seccomp.mode == SECCOMP_MODE_STRICT ||
> +            current->seccomp.mode == SECCOMP_MODE_FILTER) &&
> +           current->seccomp.mode != seccomp_mode)
> +               return true;

AFAICT, the only valid "combined" case is current->seccomp.mode==FILTER
and seccomp_mode==STRICT.   There are other allowed transitions, but
not allowed for transitioning from FILTER->STRICT via COMBINED.

If this wasn't subsuming the update access check, then the single allowed
transition could be checked in set_mode_strict() (or a helper).

>
> -       return true;
> +       return false;
>  }
>
>  void __weak arch_seccomp_spec_mitigate(struct task_struct *task) { }
> @@ -1407,6 +1416,9 @@ int __secure_computing(void)
>                 WARN_ON_ONCE(1);
>                 do_exit(SIGKILL);
>                 return -1;
> +       case SECCOMP_MODE_COMBINED:
> +               __secure_computing_strict(this_syscall);
> +               return __seccomp_filter(this_syscall, false);
>         default:
>                 BUG();
>         }
> @@ -1421,30 +1433,23 @@ long prctl_get_seccomp(void)
>  /**
>   * seccomp_set_mode_strict: internal function for setting strict seccomp
>   *
> - * Once current->seccomp.mode is non-zero, it may not be changed.
> + * Once current->seccomp.mode is non-zero, it may only be changed to `COMBINED` or `DEAD`.
>   *
> - * Returns 0 on success or -EINVAL on failure.
>   */
> -static long seccomp_set_mode_strict(void)
> +static void seccomp_set_mode_strict(void)
>  {
> -       const unsigned long seccomp_mode = SECCOMP_MODE_STRICT;
> -       long ret = -EINVAL;
> +       unsigned long seccomp_mode = SECCOMP_MODE_STRICT;
>
>         spin_lock_irq(&current->sighand->siglock);
>
> -       if (!seccomp_may_assign_mode(seccomp_mode))
> -               goto out;
> +       if (seccomp_needs_combined(seccomp_mode))
> +               seccomp_mode = SECCOMP_MODE_COMBINED;
>
>  #ifdef TIF_NOTSC
>         disable_TSC();
>  #endif
>         seccomp_assign_mode(current, seccomp_mode, 0);
> -       ret = 0;
> -
> -out:
>         spin_unlock_irq(&current->sighand->siglock);
> -
> -       return ret;

Is this reachable when mode is DEAD? In its current form, it would fail
out on may_assign_mode(), but now you have to consider if a race
could silently clobber the DEAD value (let's say).

>  }
>
>  #ifdef CONFIG_SECCOMP_FILTER
> @@ -1956,7 +1961,7 @@ static bool has_duplicate_listener(struct seccomp_filter *new_child)
>  static long seccomp_set_mode_filter(unsigned int flags,
>                                     const char __user *filter)
>  {
> -       const unsigned long seccomp_mode = SECCOMP_MODE_FILTER;
> +       long seccomp_mode = SECCOMP_MODE_FILTER;
>         struct seccomp_filter *prepared = NULL;
>         long ret = -EINVAL;
>         int listener = -1;
> @@ -2016,8 +2021,8 @@ static long seccomp_set_mode_filter(unsigned int flags,
>
>         spin_lock_irq(&current->sighand->siglock);
>
> -       if (!seccomp_may_assign_mode(seccomp_mode))
> -               goto out;
> +       if (seccomp_needs_combined(seccomp_mode))
> +               seccomp_mode = SECCOMP_MODE_COMBINED;

So I have two concerns here --

1. By layering, STRICT becomes subject to FILTER RET behaviors.
2. If we did want to layer them, it would be ideal to separate the 'upgrade'
    decision from the access checks and make the layering path explicit.

If you are running a legacy binary that uses STRICT in Docker, then I
understand the goal, but there are userspace options.

I think it's hard to want to open the door on changing STRICT without
a good reason to work through all the implications that come with it:
cross-checking every SECCOMP_MODE_FILTER reference, sorting
out thread sync interactions, ...

That said, this change could be streamlined and look for ways
to minimize any potential implications.

Am I missing something or overstating it?

Thanks!
will

>
>         if (has_duplicate_listener(prepared)) {
>                 ret = -EBUSY;
> @@ -2105,7 +2110,8 @@ static long do_seccomp(unsigned int op, unsigned int flags,
>         case SECCOMP_SET_MODE_STRICT:
>                 if (flags != 0 || uargs != NULL)
>                         return -EINVAL;
> -               return seccomp_set_mode_strict();
> +               seccomp_set_mode_strict();
> +               return 0;
>         case SECCOMP_SET_MODE_FILTER:
>                 return seccomp_set_mode_filter(flags, uargs);
>         case SECCOMP_GET_ACTION_AVAIL:
>
> --
> 2.54.0
>

Re: [PATCH RESEND 1/2] seccomp: Allow using `SECCOMP_MODE_STRICT` with `SECCOMP_MODE_FILTER`

[Andy Lutomirski]

On Fri, Jun 12, 2026 at 12:25 PM Will Drewry <wad@chromium.org> wrote:
>
> On Tue, May 26, 2026 at 10:42 AM Jamie Hill-Daniel <clubby789@gmail.com> wrote:
> >
> > It is currently impossible to enable `SECCOMP_MODE_STRICT` if
> > `SECCOMP_MODE_FILTER` is enabled, and vice-versa. This makes using
> > seccomp difficult in environments such as Docker, which installs a
> > seccomp filter by default.
>
> Some quick thoughts on your resend -- the original reasons for
> this approach:
> (a) filter policy != strict policy
> (b) filter can implement strict, if layering is desired
> (c) minimize checks in the syscall entry/return path
>
> I'd expected folks to simply create the ~80 byte strict filter and install
> it if they needed STRICT policy.

I wonder if It would be reasonable to have the kernel do this on
behalf of the user program that's asking for STRICT.  The
implementation would probably be trivial.

--Andy

Re: [PATCH RESEND 1/2] seccomp: Allow using `SECCOMP_MODE_STRICT` with `SECCOMP_MODE_FILTER`

[clubby789]

On Fri, Jun 12, 2026 at 10:24 PM Andy Lutomirski <luto@amacapital.net> wrote:
>
> I wonder if It would be reasonable to have the kernel do this on
> behalf of the user program that's asking for STRICT.  The
> implementation would probably be trivial.

I experimented with this approach after the initial AI review, but it
turned out surprisingly complex,
requiring a decent amount of refactoring to allow installing
kernel-resident programs. The filter
itself is also rather complex (mostly due to needing to account for
BPF jump sizes, which differ
as different configs (uprobe, uretprobe, SECCOMP_ARCH_COMPAT) have
different logic., and I'd worry about
keeping logic synced.
If that approach is worth pursuing though, I can submit that version
of this patch.

- Jamie

Re: [PATCH RESEND 1/2] seccomp: Allow using `SECCOMP_MODE_STRICT` with `SECCOMP_MODE_FILTER`

[Andy Lutomirski]

On Fri, Jun 12, 2026 at 3:02 PM clubby789 <clubby789@gmail.com> wrote:
>
> On Fri, Jun 12, 2026 at 10:24 PM Andy Lutomirski <luto@amacapital.net> wrote:
> >
> > I wonder if It would be reasonable to have the kernel do this on
> > behalf of the user program that's asking for STRICT.  The
> > implementation would probably be trivial.
>
> I experimented with this approach after the initial AI review, but it
> turned out surprisingly complex,
> requiring a decent amount of refactoring to allow installing
> kernel-resident programs.

Maybe so.  But there is a function bpf_prog_create (as opposed to
bpf_prog_create_from_user).

> The filter
> itself is also rather complex (mostly due to needing to account for
> BPF jump sizes, which differ
> as different configs (uprobe, uretprobe, SECCOMP_ARCH_COMPAT) have
> different logic., and I'd worry about
> keeping logic synced.

Perhaps you and your AI could elaborate?  What are these jump sizes?

In any case, I think the actual issue is that the STRICT filter's
failure case doesn't quite correspond to any of the FILTER actions.
So maybe it's too complex to be worthwhile.

--Andy

Re: [PATCH RESEND 1/2] seccomp: Allow using `SECCOMP_MODE_STRICT` with `SECCOMP_MODE_FILTER`

[clubby789]

On Fri, Jun 12, 2026 at 11:37 PM Andy Lutomirski <luto@amacapital.net> wrote:
> > The filter
> > itself is also rather complex (mostly due to needing to account for
> > BPF jump sizes, which differ
> > as different configs (uprobe, uretprobe, SECCOMP_ARCH_COMPAT) have
> > different logic., and I'd worry about
> > keeping logic synced.
>
> Perhaps you and your AI could elaborate?  What are these jump sizes?
>
> In any case, I think the actual issue is that the STRICT filter's
> failure case doesn't quite correspond to any of the FILTER actions.
> So maybe it's too complex to be worthwhile.
>
> --Andy

The filter as implemented looks approximately like

load arch
#ifdef SECCOMP_ARCH_COMPAT
    if arch == compat: goto check_compat
#endif
if arch != native arch: goto kill
load syscall nr
if syscall == {read/write/exit/sigreturn}: goto allow
#ifdef URETPROBE
    if syscall == uretprobe: goto allow
#endif
#ifdef UPROBE
    if syscall == uprobe: goto allow
#endif
ret kill
#ifdef SECCOMP_ARCH_COMPAT
    check_compat:
    if syscall == {read/write/exit/sigreturn}: goto allow
    ret kill
#endif
allow:
ret allow

The offsets from each instruction to 'allow' will differ based on the
presence of various options.
I came up with an approach using an enum for numbering each step like so:
> enum {
>   SF_LD_ARCH = 0,
> #ifdef SECCOMP_ARCH_COMPAT
>   SF_JEQ_COMPAT_ARCH,
> #endif
>   SF_JEQ_NATIVE_ARCH,
>  /* ... */
> }
> #define SF_REL(from, to) ((__u8)((to) - (from) - 1))
> static const struct sock_filter seccomp_strict_filter[] = {
>     [SF_LD_ARCH] = BPF_STMT(...),
> #ifdef SECCOMP_ARCH_COMPAT
>     [SF_JEQ_COMPAT_ARCH] = BPF_JUMP(..., SF_REL(SF_JEQ_COMPAT_ARCH, SF_LD_NR_COMPAT))
> #endif
>     /* ... */
> };

But I'm not convinced it's entirely readable/maintainable.

And just to be clear, I'm not using an AI personally; I was referring
to the Sashiko review bot, which I've now realised does not reply-all
with its reviews.

Re: [PATCH RESEND 1/2] seccomp: Allow using `SECCOMP_MODE_STRICT` with `SECCOMP_MODE_FILTER`

[clubby789]

On Fri, Jun 12, 2026 at 8:25 PM Will Drewry <wad@chromium.org> wrote:
>
> So I have two concerns here --
>
> 1. By layering, STRICT becomes subject to FILTER RET behaviors.
> 2. If we did want to layer them, it would be ideal to separate the 'upgrade'
>     decision from the access checks and make the layering path explicit.
>
> If you are running a legacy binary that uses STRICT in Docker, then I
> understand the goal, but there are userspace options.
>
> I think it's hard to want to open the door on changing STRICT without
> a good reason to work through all the implications that come with it:
> cross-checking every SECCOMP_MODE_FILTER reference, sorting
> out thread sync interactions, ...
>
> That said, this change could be streamlined and look for ways
> to minimize any potential implications.
>
> Am I missing something or overstating it?
>
> Thanks!

Thanks for the review - I'm currently working on a new version which
addresses some of the implementation
issues. On the semantics side:
The current version runs strict checks before filters. I think it
makes more sense to run filters, run strict checks, then return the
filter result (assuming strict checks were survived)
Since the strict checks logically work as another filter layer,
documentation says
> Synchronization will fail if another thread in the same process is in SECCOMP_MODE_STRICT
So refusing to sync threads which are using both modes seems the most
reasonable.

Re: [PATCH RESEND 1/2] seccomp: Allow using `SECCOMP_MODE_STRICT` with `SECCOMP_MODE_FILTER`

[Andy Lutomirski]

On Fri, Jun 12, 2026 at 3:37 PM clubby789 <clubby789@gmail.com> wrote:
>
> On Fri, Jun 12, 2026 at 8:25 PM Will Drewry <wad@chromium.org> wrote:
> >
> > So I have two concerns here --
> >
> > 1. By layering, STRICT becomes subject to FILTER RET behaviors.
> > 2. If we did want to layer them, it would be ideal to separate the 'upgrade'
> >     decision from the access checks and make the layering path explicit.
> >
> > If you are running a legacy binary that uses STRICT in Docker, then I
> > understand the goal, but there are userspace options.
> >
> > I think it's hard to want to open the door on changing STRICT without
> > a good reason to work through all the implications that come with it:
> > cross-checking every SECCOMP_MODE_FILTER reference, sorting
> > out thread sync interactions, ...
> >
> > That said, this change could be streamlined and look for ways
> > to minimize any potential implications.
> >
> > Am I missing something or overstating it?
> >
> > Thanks!
>
> Thanks for the review - I'm currently working on a new version which
> addresses some of the implementation
> issues. On the semantics side:
> The current version runs strict checks before filters. I think it
> makes more sense to run filters, run strict checks, then return the
> filter result (assuming strict checks were survived)
> Since the strict checks logically work as another filter layer,
> documentation says
> > Synchronization will fail if another thread in the same process is in SECCOMP_MODE_STRICT
> So refusing to sync threads which are using both modes seems the most
> reasonable.


Can we take a moment to contemplate how filters compose?  The current rule is:

/*
 * All BPF programs must return a 32-bit value.
 * The bottom 16-bits are for optional return data.
 * The upper 16-bits are ordered from least permissive values to most,
 * as a signed value (so 0x8000000 is negative).
 *
 * The ordering ensures that a min_t() over composed return values always
 * selects the least permissive choice.
 */
#define SECCOMP_RET_KILL_PROCESS 0x80000000U /* kill the process */
#define SECCOMP_RET_KILL_THREAD  0x00000000U /* kill the thread */
#define SECCOMP_RET_KILL         SECCOMP_RET_KILL_THREAD
#define SECCOMP_RET_TRAP         0x00030000U /* disallow and force a SIGSYS */
#define SECCOMP_RET_ERRNO        0x00050000U /* returns an errno */
#define SECCOMP_RET_USER_NOTIF   0x7fc00000U /* notifies userspace */
#define SECCOMP_RET_TRACE        0x7ff00000U /* pass to a tracer or disallow */
#define SECCOMP_RET_LOG          0x7ffc0000U /* allow after logging */
#define SECCOMP_RET_ALLOW        0x7fff0000U /* allow */

This has always bothered me.  In the absence of USER_NOTIF and TRACE,
fine, I guess -- we're choosing the least permissive, and this doesn't
seem too crazy.

But TRACE and USER_NOTIF make this very strange, especially as people
keep wanting, quite reasonably, to make USER_NOTIF fancier.  Shouldn't
the actual behavior be that each filter, starting from the innermost,
gets to reject or transform a system call, and the outer filters
should act on the result *after transformation* of the syscall?

For example, if I run a container and set some syscall foobar() to
SECCOMP_RET_ERROR in the container's policy, and the container them
runs a tool that sets foobar() to TRACE, then I think it would make a
lot more sense for the tracer get notified if the task calls foobar().
Or if the container sets foobar() to USER_NOTIF and tries to emulate
it, then it should emulate (and not get ERRORed because no actual
foobar() syscall has been attempted now that the inner filter was
evaluated) and then run the result of USER_NOTIF emulation (assuming
it tries to do a syscall) through the outer syscall?

And, however, this gets done, presumably STRICT would be a different
variant of KILL_PROCESS that does SIGKILL.

--Andy

[PATCH RESEND 2/2] selftest: seccomp: Adjust test for using both `STRICT` and `FILTER`

[Jamie Hill-Daniel]

This test previously tested that applying `STRICT` after `FILTER` is
impossible - update it to test that it is now possible.

Signed-off-by: Jamie Hill-Daniel <jamie@hill-daniel.co.uk>
---
 tools/testing/selftests/seccomp/seccomp_bpf.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c b/tools/testing/selftests/seccomp/seccomp_bpf.c
index 874f17763536..ba042828dcbd 100644
--- a/tools/testing/selftests/seccomp/seccomp_bpf.c
+++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
@@ -516,7 +516,7 @@ TEST(filter_chain_limits)
 	}
 }
 
-TEST(mode_filter_cannot_move_to_strict)
+TEST(mode_filter_combined)
 {
 	struct sock_filter filter[] = {
 		BPF_STMT(BPF_RET|BPF_K, SECCOMP_RET_ALLOW),
@@ -534,8 +534,7 @@ TEST(mode_filter_cannot_move_to_strict)
 	ASSERT_EQ(0, ret);
 
 	ret = prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT, NULL, 0, 0);
-	EXPECT_EQ(-1, ret);
-	EXPECT_EQ(EINVAL, errno);
+	ASSERT_EQ(0, ret);
 }
 
 

-- 
2.54.0

Re: [PATCH RESEND 2/2] selftest: seccomp: Adjust test for using both `STRICT` and `FILTER`

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Medium] The updated selftests crash with SIGKILL due to unhandled strict seccomp constraints.

Pre-existing issues:
- [Critical] The internal kernel mode `SECCOMP_MODE_COMBINED` is leaked to userspace via `prctl` and `/proc/pid/status`, causing ABI breakage.
--

commit fb241f2f33856c48dd4d8cab04014fc026770de7
Author: Jamie Hill-Daniel <clubby789@gmail.com>

selftest: seccomp: Adjust test for using both STRICT and FILTER

This patch updates the seccomp selftests to expect a successful transition
to STRICT mode after FILTER mode is already applied, renaming the test
to mode_filter_combined.

> --- a/tools/testing/selftests/seccomp/seccomp_bpf.c
> +++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
[ ... ]
> -TEST(mode_filter_cannot_move_to_strict)
> +TEST(mode_filter_combined)
>  {
>  	struct sock_filter filter[] = {
>  		BPF_STMT(BPF_RET|BPF_K, SECCOMP_RET_ALLOW),
> @@ -534,8 +534,7 @@ TEST(mode_filter_cannot_move_to_strict)
>  	ASSERT_EQ(0, ret);
>  
>  	ret = prctl(PR_SET_SECCOMP, SECCOMP_MODE_STRICT, NULL, 0, 0);
> -	EXPECT_EQ(-1, ret);
> -	EXPECT_EQ(EINVAL, errno);
> +	ASSERT_EQ(0, ret);

[Severity: Medium]
When this test finishes, the kselftest framework attempts to exit the process
by calling glibc's _exit(), which invokes the exit_group syscall.

Since strict seccomp mode only permits read, write, _exit (__NR_exit),
and sigreturn, won't the forbidden exit_group syscall cause the test process
to be immediately killed with SIGKILL?

It appears the test must manually exit via syscall(__NR_exit, 0) to avoid
falsely reporting a failure, similar to how TEST(mode_strict_support)
handles it.

Additionally, does this patch also need to update
TEST(seccomp_syscall_mode_lock)?

With the new kernel behavior, that test's transition to strict mode will now
succeed, causing it to execute the seccomp() syscall while in strict mode,
which will result in another immediate SIGKILL.

[Severity: Critical]
This is a pre-existing issue, but the underlying kernel patch appears to leak
the internal SECCOMP_MODE_COMBINED (4) state to userspace.

When a process successfully transitions to strict mode after a filter is
installed, its internal state becomes 4.

If this value is directly exposed to userspace via prctl(PR_GET_SECCOMP)
and the /proc/pid/status file's Seccomp: field, could this break ABI
contracts?

The UAPI headers only define SECCOMP_MODE_DISABLED (0), 
SECCOMP_MODE_STRICT (1), and SECCOMP_MODE_FILTER (2). 

Exposing an undocumented internal mode to userspace might cause sandbox
monitoring tools, init systems, or security daemons that expect standard
UAPI values to malfunction or crash.

>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260526-seccomp-combined-v1-0-304b1cc3ad24@hill-daniel.co.uk?part=2

Re: [PATCH RESEND 0/2] seccomp: Allow using `SECCOMP_MODE_STRICT` with `SECCOMP_MODE_FILTER`

[Kees Cook]

On Tue, May 26, 2026 at 04:32:14PM +0100, Jamie Hill-Daniel wrote:
> This patch adjusts the logic used by seccomp to allow applying both
> `SECCOMP_MODE_FILTER` and `SECCOMP_MODE_STRICT` to the same process.

Honestly, SECCOMP_MODE_STRICT is kinda deprecated. Nothing new should be
using it.

> Currently, once seccomp has been initialized, a process may not
> transition to a different mode (only add additional filters).
> This means that in container environments such as Docker, which by
> default runs with `SECCOMP_MODE_FILTER`, processes may not enable
> `SECCOMP_MODE_STRICT`. This is an obstacle to using applications
> requiring `SECCOMP_MODE_STRICT` in these environments, and requires
> disabling these security measures.

What applications do you have that need SECCOMP_MODE_STRICT and why
can't they be modified to use FILTER?

> When subsequently running secure computing checks, we run the strict
> checks followed by any installed filters.
> 
> Link: https://github.com/moby/moby/issues/42082

This doesn't show any particular application, just a demo program.

I'd *really* prefer to only add complexity to seccomp if it is
absolutely needed.

-Kees

-- 
Kees Cook

Re: [PATCH RESEND 0/2] seccomp: Allow using `SECCOMP_MODE_STRICT` with `SECCOMP_MODE_FILTER`

[Jamie Hill-Daniel]

On Sat, Jun 13, 2026 at 5:14 AM Kees Cook <kees@kernel.org> wrote:
> On Tue, May 26, 2026 at 04:32:14PM +0100, Jamie Hill-Daniel wrote:
> > Link: https://github.com/moby/moby/issues/42082
>
> This doesn't show any particular application, just a demo program.
>
> I'd *really* prefer to only add complexity to seccomp if it is
> absolutely needed.

When I filed the original issue it was attempting a minimised
reproduction; I was trying to run some legacy binary in a container
that I unfortunately don't have the context for any more.
I've submitted another series that should hopefully address some of
the concerns raised here, including complexity.

Re: [PATCH RESEND 0/2] seccomp: Allow using `SECCOMP_MODE_STRICT` with `SECCOMP_MODE_FILTER`

[Kees Cook]

On Mon, Jun 15, 2026 at 05:23:53PM +0100, Jamie Hill-Daniel wrote:
> On Sat, Jun 13, 2026 at 5:14 AM Kees Cook <kees@kernel.org> wrote:
> > On Tue, May 26, 2026 at 04:32:14PM +0100, Jamie Hill-Daniel wrote:
> > > Link: https://github.com/moby/moby/issues/42082
> >
> > This doesn't show any particular application, just a demo program.
> >
> > I'd *really* prefer to only add complexity to seccomp if it is
> > absolutely needed.
> 
> When I filed the original issue it was attempting a minimised
> reproduction; I was trying to run some legacy binary in a container
> that I unfortunately don't have the context for any more.
> I've submitted another series that should hopefully address some of
> the concerns raised here, including complexity.

Right, I think I'd prefer the legacy binary be adjusted instead. And not
adding complexity to seccomp given the issue isn't actually a problem
any more. :)

-- 
Kees Cook

Re: [PATCH RESEND 0/2] seccomp: Allow using `SECCOMP_MODE_STRICT` with `SECCOMP_MODE_FILTER`

[Kees Cook]

On Mon, Jun 15, 2026 at 03:38:35PM -0700, Kees Cook wrote:
> On Mon, Jun 15, 2026 at 05:23:53PM +0100, Jamie Hill-Daniel wrote:
> > On Sat, Jun 13, 2026 at 5:14 AM Kees Cook <kees@kernel.org> wrote:
> > > On Tue, May 26, 2026 at 04:32:14PM +0100, Jamie Hill-Daniel wrote:
> > > > Link: https://github.com/moby/moby/issues/42082
> > >
> > > This doesn't show any particular application, just a demo program.
> > >
> > > I'd *really* prefer to only add complexity to seccomp if it is
> > > absolutely needed.
> > 
> > When I filed the original issue it was attempting a minimised
> > reproduction; I was trying to run some legacy binary in a container
> > that I unfortunately don't have the context for any more.
> > I've submitted another series that should hopefully address some of
> > the concerns raised here, including complexity.
> 
> Right, I think I'd prefer the legacy binary be adjusted instead. And not
> adding complexity to seccomp given the issue isn't actually a problem
> any more. :)

And here's a wrapper, if there's no source for the binary:
https://github.com/kees/kernel-tools/blob/trunk/seccomp/strict_launcher.c

(This could probably be improved...)

-Kees

-- 
Kees Cook