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
WARNING: multiple messages have this Message-ID (diff)
From: Paul Moore <paul@paul-moore.com> To: "Thomas Weißschuh" <linux@weissschuh.net> Cc: bpf@vger.kernel.org, linux-audit@redhat.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) 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 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
next prev parent reply other threads:[~2021-06-29 23:41 UTC|newest] Thread overview: 16+ 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 7:31 ` Thomas Weißschuh 2021-06-28 16:59 ` Paul Moore 2021-06-28 16:59 ` Paul Moore 2021-06-28 17:13 ` Thomas Weißschuh 2021-06-28 17:13 ` Thomas Weißschuh 2021-06-28 17:34 ` Paul Moore 2021-06-28 17:34 ` Paul Moore 2021-06-28 17:58 ` Thomas Weißschuh 2021-06-28 17:58 ` Thomas Weißschuh 2021-06-28 22:43 ` Paul Moore 2021-06-28 22:43 ` Paul Moore 2021-06-29 10:40 ` Thomas Weißschuh 2021-06-29 10:40 ` Thomas Weißschuh 2021-06-29 23:41 ` Paul Moore [this message] 2021-06-29 23:41 ` Paul Moore
Reply instructions: 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAHC9VhSzqfnWUu=L2sW44S1y4TKR1j6=CV5rWRwsnHvZPdfrgA@mail.gmail.com' \ --to=paul@paul-moore.com \ --cc=bpf@vger.kernel.org \ --cc=linux-audit@redhat.com \ --cc=linux@weissschuh.net \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.