Re: AUDIT_ARCH_ and __NR_syscall constants for seccomp filters

From: Paul Moore <paul@paul-moore.com>
To: "Thomas Weißschuh" <linux@weissschuh.net>
Cc: linux-audit@redhat.com, bpf@vger.kernel.org
Subject: Re: AUDIT_ARCH_ and __NR_syscall constants for seccomp filters
Date: Tue, 29 Jun 2021 19:41:43 -0400	[thread overview]
Message-ID: <CAHC9VhSzqfnWUu=L2sW44S1y4TKR1j6=CV5rWRwsnHvZPdfrgA@mail.gmail.com> (raw)
In-Reply-To: <60ba7e11-36af-4b24-9132-c5214f32bdad@t-8ch.de>

On Tue, Jun 29, 2021 at 6:40 AM Thomas Weißschuh <linux@weissschuh.net> wrote:
>
> On Mo, 2021-06-28T18:43-0400, Paul Moore wrote:
> > On Mon, Jun 28, 2021 at 1:58 PM Thomas Weißschuh <linux@weissschuh.net> wrote:
> > >
> > > Hi again!
> >
> > !!! :)
>
> Indeed, hi!

'sup.

> > > On Mo, 2021-06-28T13:34-0400, Paul Moore wrote:
> > > > On Mon, Jun 28, 2021 at 1:13 PM Thomas Weißschuh <linux@weissschuh.net> wrote:
> > > > > On Mo, 2021-06-28T12:59-0400, Paul Moore wrote:
> > > > > > On Mon, Jun 28, 2021 at 9:25 AM Thomas Weißschuh <linux@weissschuh.net> wrote:

...

> To get back to my other question:
>
> Is there any chance a single given process can have multiple different ABIs
> active at the same time?
> Without using special syscalls to switch between them.
>
> Because if that is not possible I can skip the checks for the arch completely
> because the filter is constructed at compile time for the specific ABI
> targetted and all funky syscalls are forbidden anyways.

Is it common for a single executing process/executable to use multiple
ABIs?  No, I don't think so, although maybe someone can provide an
example where this happens normally.  However, don't ignore what might
be possible from a malicious userspace. :)

> PS: I know that this seems to be a lot of discussion for fairly little gain in
> this specific case, but I'd like to use seccomp filters in the future more and
> am trying to find the most unobtrusive way to add them to applications for each
> given usecase.
> (For any larger applications that will certainly include libseccomp, but that
> feels overkill for very specific, zero-runtime-dependency utilities)

One thing to keep in mind is the maintainability of these tools you
are creating.  For example, several years ago there was no such thing
as direct socket syscalls on 32-bit x86, but now they exist alongside
the legacy socketcall() syscall.  Do your custom seccomp filters
handle that properly, for all combinations of kernel and libc?  What
about your older tools that were written back when socketcall() was
the only option?

There is also the issue of x86_64 and x32, but that may be of little
interest to you, and I hear that x32 may be deprecated in the future
(woo hoo!).

Regardless, there are lots of interesting corner cases with seccomp so
I would urge you to do your homework before using custom filters in
critical tools.

Good luck!

-- 
paul moore
www.paul-moore.com