linux-kernel - Re: Using ftrace/perf as a basis for generic seccomp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 03 Feb 2011 20:50:26 -0500
From:	Eric Paris <eparis@...hat.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Stefan Fritsch <sf@...itsch.de>, Ingo Molnar <mingo@...e.hu>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	linux-kernel@...r.kernel.org, agl@...gle.com, tzanussi@...il.com,
	Jason Baron <jbaron@...hat.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	2nddept-manager@....hitachi.co.jp,
	Steven Rostedt <rostedt@...dmis.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: Using ftrace/perf as a basis for generic seccomp

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/