linux-kernel - Re: [PATCH v6 6/9] kernel: entry: Support Syscall User Dispatch for common syscall entry

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <0639209E-B6C6-4F86-84F4-04B91E1CC8AA@amacapital.net>
Date:   Mon, 7 Sep 2020 07:15:52 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     Christian Brauner <christian.brauner@...ntu.com>
Cc:     Gabriel Krisman Bertazi <krisman@...labora.com>, luto@...nel.org,
        tglx@...utronix.de, keescook@...omium.org, x86@...nel.org,
        linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
        willy@...radead.org, linux-kselftest@...r.kernel.org,
        shuah@...nel.org, kernel@...labora.com
Subject: Re: [PATCH v6 6/9] kernel: entry: Support Syscall User Dispatch for common syscall entry



> On Sep 7, 2020, at 3:15 AM, Christian Brauner <christian.brauner@...ntu.com> wrote:
> 
> On Fri, Sep 04, 2020 at 04:31:44PM -0400, Gabriel Krisman Bertazi wrote:
>> Syscall User Dispatch (SUD) must take precedence over seccomp, since the
>> use case is emulation (it can be invoked with a different ABI) such that
>> seccomp filtering by syscall number doesn't make sense in the first
>> place.  In addition, either the syscall is dispatched back to userspace,
>> in which case there is no resource for seccomp to protect, or the
> 
> Tbh, I'm torn here. I'm not a super clever attacker but it feels to me
> that this is still at least a clever way to circumvent a seccomp
> sandbox.
> If I'd be confined by a seccomp profile that would cause me to be
> SIGKILLed when I try do open() I could prctl() myself to do user
> dispatch to prevent that from happening, no?
> 

Not really, I think. The idea is that you didn’t actually do open(). You did a SYSCALL instruction which meant something else, and the syscall dispatch correctly prevented the kernel from misinterpreting it as open().