From: Paul Moore <firstname.lastname@example.org>
To: "Thomas Weißschuh" <email@example.com>
Cc: firstname.lastname@example.org, email@example.com
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)
On Tue, Jun 29, 2021 at 6:40 AM Thomas Weißschuh <firstname.lastname@example.org> wrote:
> On Mo, 2021-06-28T18:43-0400, Paul Moore wrote:
> > On Mon, Jun 28, 2021 at 1:58 PM Thomas Weißschuh <email@example.com> wrote:
> > >
> > > Hi again!
> > !!! :)
> Indeed, hi!
> > > On Mo, 2021-06-28T13:34-0400, Paul Moore wrote:
> > > > On Mon, Jun 28, 2021 at 1:13 PM Thomas Weißschuh <firstname.lastname@example.org> wrote:
> > > > > On Mo, 2021-06-28T12:59-0400, Paul Moore wrote:
> > > > > > On Mon, Jun 28, 2021 at 9:25 AM Thomas Weißschuh <email@example.com> 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
Regardless, there are lots of interesting corner cases with seccomp so
I would urge you to do your homework before using custom filters in
prev parent reply other threads:[~2021-06-29 23:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-28 7:31 AUDIT_ARCH_ and __NR_syscall constants for seccomp filters Thomas Weißschuh
2021-06-28 16:59 ` Paul Moore
2021-06-28 17:13 ` Thomas Weißschuh
2021-06-28 17:34 ` Paul Moore
2021-06-28 17:58 ` Thomas Weißschuh
2021-06-28 22:43 ` Paul Moore
2021-06-29 10:40 ` Thomas Weißschuh
2021-06-29 23:41 ` Paul Moore [this message]
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).