LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Eric Paris <eparis@redhat.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Stefan Fritsch <sf@sfritsch.de>, Ingo Molnar <mingo@elte.hu>,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	linux-kernel@vger.kernel.org, agl@google.com, tzanussi@gmail.com,
	Jason Baron <jbaron@redhat.com>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	2nddept-manager@sdl.hitachi.co.jp,
	Steven Rostedt <rostedt@goodmis.org>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: Re: Using ftrace/perf as a basis for generic seccomp
Date: Thu, 03 Feb 2011 20:50:26 -0500	[thread overview]
Message-ID: <1296784230.3145.44.camel@localhost.localdomain> (raw)
In-Reply-To: <20110203231051.GA1840@nowhere>

On Fri, 2011-02-04 at 00:10 +0100, Frederic Weisbecker wrote:
> On Thu, Feb 03, 2011 at 11:06:33PM +0100, Stefan Fritsch wrote:
> > On Thursday 03 February 2011, Frederic Weisbecker wrote:

> Actually having seccomp as a user of filter expressions is a opportunity
> to improve it and bring new ideas.
> 
> > This would give something in the very near future that is way more 
> > usable than seccomp mode 1. I think only the following adjustments 
> > would need to be made to Adam Langley's patch:
> > 
> > - only allow syscalls in the mode (non-compat/compat) that the prctl 
> > call was made in
> > - deny exec of setuid/setgid binaries
> > - deny exec of binaries with filesystem capabilities
> > 
> > What do you think of this proposal? I have a patch lying around 
> > somewhere that already does the first two of these.
> 
> IMHO this is an unnecessary intermediate state. It will actually make
> things worse by bringing a new non-flexible ABI that we'll need to
> maintain forever.
> 
> I'm no expert in security but I think it's not flexible.

I'm not quite sure how I feel.  The only person who ask/semi-required
this flexibility is Ingo.  I agree it's a really great idea and maybe
one that people will someday use.  I'm going to try to work on it over
the next week or two.  I'm not certain if my use case really wants/needs
it or will even use the filter flexibility.  Now, there's no question
that what we have today is so inflexible it's basically useless.  It's
also obvious that we have at least 3 people who would use something like
the google solution.  (sounds like at least 3 of us have written a
google like solution by now)

So I'm going to take a stab at understanding everything you told me
today.  THANK YOU SO MUCH for the overview.  It was AMAZING and exactly
what I was hoping to hear.  But if I don't think I can come up with
something in a reasonable time frame I'm probably going to be back
pushing what we all wanted to start with    :)

-Eric


  reply	other threads:[~2011-02-04  1:51 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-12 21:28 Eric Paris
2011-02-01 14:58 ` Eric Paris
2011-02-02 12:14   ` Masami Hiramatsu
2011-02-02 12:26     ` Ingo Molnar
2011-02-02 16:45       ` Eric Paris
2011-02-02 17:55         ` Ingo Molnar
2011-02-02 18:17           ` Steven Rostedt
2011-02-03 19:06         ` Frederic Weisbecker
2011-02-03 19:18           ` Frederic Weisbecker
2011-02-03 22:06           ` Stefan Fritsch
2011-02-03 23:10             ` Frederic Weisbecker
2011-02-04  1:50               ` Eric Paris [this message]
2011-02-04 14:31                 ` Peter Zijlstra
2011-02-04 16:29                   ` Eric Paris
2011-02-04 17:04                     ` Frederic Weisbecker
2011-02-05 11:51                       ` Stefan Fritsch
2011-02-07 12:26                         ` Peter Zijlstra
2011-02-04 16:36             ` Eric Paris
2011-02-05 11:42               ` Stefan Fritsch
2011-02-06 16:51                 ` Eric Paris

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=1296784230.3145.44.camel@localhost.localdomain \
    --to=eparis@redhat.com \
    --cc=2nddept-manager@sdl.hitachi.co.jp \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@redhat.com \
    --cc=agl@google.com \
    --cc=fweisbec@gmail.com \
    --cc=jbaron@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    --cc=sf@sfritsch.de \
    --cc=tglx@linutronix.de \
    --cc=tzanussi@gmail.com \
    --subject='Re: Using ftrace/perf as a basis for generic seccomp' \
    /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

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