public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Will Drewry <wad@chromium.org>
Cc: James Morris <jmorris@namei.org>,
	Chris Evans <scarybeasts@gmail.com>,
	linux-kernel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	djm@mindrot.org, segoon@openwall.com, kees.cook@canonical.com,
	rostedt@goodmis.org, fweisbec@gmail.com, tglx@linutronix.de,
	Randy Dunlap <rdunlap@xenotime.net>,
	linux-doc@vger.kernel.org, Eric Paris <eparis@redhat.com>,
	linux-security-module@vger.kernel.org
Subject: Re: [PATCH v9 05/13] seccomp_filter: Document what seccomp_filter is and how it works.
Date: Tue, 5 Jul 2011 11:50:19 +0200	[thread overview]
Message-ID: <20110705095019.GC5725@elte.hu> (raw)
In-Reply-To: <BANLkTik2YtBbC+T3zyCooK71zZ_z2FdJuQ@mail.gmail.com>


* Will Drewry <wad@chromium.org> wrote:

> > In the end the 'sandboxing' feature should be a few dozen lines 
> > at most - all the rest will just be shared infrastructure.
> 
> Anytime a powerful feature can be a few lines of code, it's a good 
> thing.  It seems like we're still a ways away from defining what 
> the shared infrastructure is that would allow a few dozen lines of 
> code to be enough.  The bones are there, but there's a large amount 
> of missing and under-designed work.

But adding some intermediate solution with its own ABI and its own 
forked specializations hinders (and might even prevent, if it's "good 
enough") the proper solution of this topic.

It's not like such features are in super-high demand so we *want* and 
*need* as much generalization and unification as possible, to utilize 
economies of scale and such.

There's really just two ways forward that i can see (in terms of this 
going upstream via the events/tracing/instrumentation tree that i 
co-maintain):

 1) Do it properly generalized - as shown by the prototype patch.
    I can give you all help that is needed for that: we can host
    intermediate stages in -tip and we can push upstream step by
    step. You won't have to maintain some large in-limbo set of
    patches. 95% of the work you've identified will be warmly
    welcome by everyone and will be utilized well beyond sandboxing! 
    That's not a bad starting position to get something controversial 
    upstream: most of the crazy trees are 95% crazy.

 2) Give a compelling list of technical reasons why the
    generalization is not desirable and thus go for a minimally
    invasive solution

Option #2 does not apply because you've yourself stated that the 
generalizations make a ton of sense (and even if you didnt state it 
i'd make that point).

The option you seem to have opted for:

 3) do it in a half-ways and limited fashion due to time constraints 
    and perceived upstream resistence

is not something that was a winning model in the past so i'm not 
really interested in that.

Thanks,

	Ingo

  reply	other threads:[~2011-07-05  9:51 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-24  0:36 [PATCH v9 01/13] tracing: split out filter initialization and clean up uses Will Drewry
2011-06-24  0:36 ` [PATCH v9 02/13] tracing: split out syscall_trace_enter construction Will Drewry
2011-06-24  0:36 ` [PATCH v9 03/13] seccomp_filter: new mode with configurable syscall filters Will Drewry
2011-06-24  7:30   ` Damien Miller
2011-06-24 20:20   ` Kees Cook
2011-06-24  0:36 ` [PATCH v9 04/13] seccomp_filter: add process state reporting Will Drewry
2011-06-24  0:36 ` [PATCH v9 05/13] seccomp_filter: Document what seccomp_filter is and how it works Will Drewry
2011-06-24  7:24   ` Chris Evans
     [not found]   ` <BANLkTimtYUyXbZjWhjK61B_1WBXE4MoAeA@mail.gmail.com>
2011-06-26 23:20     ` James Morris
2011-06-29 19:13       ` Will Drewry
2011-06-30  1:30         ` James Morris
2011-07-01 11:56           ` Ingo Molnar
2011-07-01 12:56             ` Will Drewry
2011-07-01 13:07               ` Ingo Molnar
2011-07-01 15:46                 ` Will Drewry
2011-07-01 16:10                   ` Ingo Molnar
2011-07-01 16:43                     ` Will Drewry
2011-07-01 18:04                       ` Steven Rostedt
2011-07-01 18:09                         ` Will Drewry
2011-07-01 18:48                           ` Steven Rostedt
2011-07-04  2:19                             ` James Morris
2011-07-05 12:40                               ` Steven Rostedt
2011-07-05 23:46                                 ` James Morris
2011-07-06  0:37                                   ` [Ksummit-2011-discuss] " Ted Ts'o
2011-07-05 23:56                               ` Steven Rostedt
2011-07-05  2:54                           ` [Ksummit-2011-discuss] " Eugene Teo
2011-07-01 20:25                         ` Kees Cook
2011-07-04 16:09                           ` [Ksummit-2011-discuss] " Greg KH
2011-07-01 21:00                       ` Ingo Molnar
2011-07-01 21:34                         ` Will Drewry
2011-07-05  9:50                           ` Ingo Molnar [this message]
2011-07-06 18:24                             ` Will Drewry
2011-07-05 15:26                 ` Vasiliy Kulikov
2011-06-24  0:36 ` [PATCH v9 06/13] x86: add HAVE_SECCOMP_FILTER and seccomp_execve Will Drewry
2011-06-24  0:36 ` [PATCH v9 07/13] arm: select HAVE_SECCOMP_FILTER Will Drewry
2011-06-24  0:36 ` [PATCH v9 08/13] microblaze: select HAVE_SECCOMP_FILTER and provide seccomp_execve Will Drewry
2011-06-24  0:36 ` [PATCH v9 09/13] mips: " Will Drewry
2011-06-24  0:36 ` [PATCH v9 10/13] s390: " Will Drewry
2011-06-24  0:36 ` [PATCH v9 11/13] powerpc: " Will Drewry
2011-08-30  5:28   ` Benjamin Herrenschmidt
2011-11-28  0:14     ` Benjamin Herrenschmidt
2011-11-28  1:45       ` Will Drewry
2011-06-24  0:36 ` [PATCH v9 12/13] sparc: " Will Drewry
2011-06-24  0:36 ` [PATCH v9 13/13] sh: select HAVE_SECCOMP_FILTER Will Drewry

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=20110705095019.GC5725@elte.hu \
    --to=mingo@elte.hu \
    --cc=djm@mindrot.org \
    --cc=eparis@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=jmorris@namei.org \
    --cc=kees.cook@canonical.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=rdunlap@xenotime.net \
    --cc=rostedt@goodmis.org \
    --cc=scarybeasts@gmail.com \
    --cc=segoon@openwall.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=wad@chromium.org \
    /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: 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