linux-kernel - Re: [PATCH v2 2/2] rusage: allow 64-bit times ru_utime/ru

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: <87y3f31wsv.fsf@xmission.com>
Date:   Sun, 24 Jun 2018 20:26:08 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Arnd Bergmann <arnd@...db.de>,
        y2038 Mailman List <y2038@...ts.linaro.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        Linux API <linux-api@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Paul Eggert <eggert@...ucla.edu>,
        Richard Henderson <rth@...ddle.net>,
        Ivan Kokshaysky <ink@...assic.park.msu.ru>,
        Matt Turner <mattst88@...il.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Dominik Brodowski <linux@...inikbrodowski.net>,
        Thomas Gleixner <tglx@...utronix.de>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-alpha@...r.kernel.org,
        Deepa Dinamani <deepa.kernel@...il.com>
Subject: Re: [PATCH v2 2/2] rusage: allow 64-bit times ru_utime/ru_stime

Ingo Molnar <mingo@...nel.org> writes:

> * Eric W. Biederman <ebiederm@...ssion.com> wrote:
>
>> The trouble with attributes is that means you can't filter your system
>> call arguments with seccomp. [...]
>
> There's nothing keeping seccomp from securely fetching those arguments and 
> extending filtering to them as well ...
>
> Allowing that would make sense for a lot of other system calls as
> well.

Possibly.  The challenge is that if the fetch for the kernel to use
those arguments is different from the fetch of seccomp to test those
arguments you have a time of test vs time of use race.

Given the location of the seccomp hook at the kernel user space border
there is no easy way for seccomp to share the fetch with the system
call itself.

So I don't see how seccomp could perform the fetch securely.

Eric