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
next prev parent 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 Using ftrace/perf as a basis for generic seccomp 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 \
/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