LKML Archive on lore.kernel.org help / color / mirror / Atom feed
From: firstname.lastname@example.org (Eric W. Biederman) To: Ingo Molnar <email@example.com> Cc: Arnd Bergmann <firstname.lastname@example.org>, y2038 Mailman List <email@example.com>, Linux Kernel Mailing List <firstname.lastname@example.org>, the arch/x86 maintainers <email@example.com>, Linux API <firstname.lastname@example.org>, linux-arch <email@example.com>, Paul Eggert <firstname.lastname@example.org>, Richard Henderson <email@example.com>, Ivan Kokshaysky <firstname.lastname@example.org>, Matt Turner <email@example.com>, Al Viro <firstname.lastname@example.org>, Dominik Brodowski <email@example.com>, Thomas Gleixner <firstname.lastname@example.org>, Andrew Morton <email@example.com>, firstname.lastname@example.org, Deepa Dinamani <email@example.com> Subject: Re: [PATCH v2 2/2] rusage: allow 64-bit times ru_utime/ru_stime Date: Mon, 25 Jun 2018 11:21:59 -0500 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <20180625091426.GA18351@gmail.com> (Ingo Molnar's message of "Mon, 25 Jun 2018 11:14:26 +0200") Ingo Molnar <email@example.com> writes: > * Eric W. Biederman <firstname.lastname@example.org> wrote: > >> Ingo Molnar <email@example.com> writes: >> >> > * Eric W. Biederman <firstname.lastname@example.org> 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. > > Those fetched values should obviously then be used to call permitted > system calls. Agreed. To my knowledge no one has figured out how to make that work yet. For the most part it has been unnecessary. >> 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. > > Looks like more of a seccomp mis-design/mis-implementation than some fundamental > problem. Frankly. Given that there are some very good solutions in other operating systems, I think the misdesign is in unix/linux not providing a good answer to what to do when you need more than 6 arguments to a system call. > Mis-designed security features should not hinder system call design. I certainly agree that seccomp should not be the sole reason for not doing something. However there are lots of reasons to avoid extensibility in general. Excess extensibility has been the cause of more than one security issue. Lots of flexibility comes at the price of lots of conditional execution which tends to explode the test matrix of possibilities to test, with the result that some combinations are never thought about or tested because they don't make sense to combine. Then someone with mischievious intent see that combination and thinks what happens when I do this. Further that conditional execution can frequently be the cause of slow code as well. So while there are many nice features of tagged values. I don't think they are a general solution. The lack of seccomp support (today) is just one downside among many. I do think it would be nice to have a general pattern for those system calls that require extensibility. My gut feel says something like the L4 pseudo registers (to give a maxium request size) combined with something like netlink encoding would make a very nice template for making fast and flexible system calls. Eric
next prev parent reply other threads:[~2018-06-25 16:22 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-04-20 12:05 [PATCH v2 1/2] y2038: rusage: Use __kernel_old_timeval for process times Arnd Bergmann 2018-04-20 12:05 ` [PATCH v2 2/2] rusage: allow 64-bit times ru_utime/ru_stime Arnd Bergmann 2018-06-21 15:49 ` Ingo Molnar 2018-06-21 16:01 ` Arnd Bergmann 2018-06-21 16:11 ` Ingo Molnar 2018-06-21 16:25 ` Arnd Bergmann 2018-06-22 2:16 ` Ingo Molnar 2018-06-22 17:45 ` Eric W. Biederman 2018-06-24 7:12 ` Ingo Molnar 2018-06-25 1:26 ` Eric W. Biederman 2018-06-25 9:14 ` Ingo Molnar 2018-06-25 16:21 ` Eric W. Biederman [this message] 2018-06-25 11:42 ` Arnd Bergmann
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 \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /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 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).