LKML Archive on
help / color / mirror / Atom feed
From: (Eric W. Biederman)
To: Ingo Molnar <>
Cc: Arnd Bergmann <>,
	y2038 Mailman List <>,
	Linux Kernel Mailing List <>,
	the arch/x86 maintainers <>,
	Linux API <>,
	linux-arch <>,
	Paul Eggert <>,
	Richard Henderson <>,
	Ivan Kokshaysky <>,
	Matt Turner <>,
	Al Viro <>,
	Dominik Brodowski <>,
	Thomas Gleixner <>,
	Andrew Morton <>,,
	Deepa Dinamani <>
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: <> (raw)
In-Reply-To: <> (Ingo Molnar's message of "Mon, 25 Jun 2018 11:14:26 +0200")

Ingo Molnar <> writes:

> * Eric W. Biederman <> wrote:
>> Ingo Molnar <> writes:
>> > * Eric W. Biederman <> 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.


  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:

* 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).