Message-ID: <CABqD9hYme6fSTfeTG+351sMu=Uh5PxE3-ASTXi8Tk17n2y_29A@mail.gmail.com>
Date:	Wed, 6 Jul 2011 13:24:22 -0500
From:	Will Drewry <wad@...omium.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	James Morris <jmorris@...ei.org>,
	Chris Evans <scarybeasts@...il.com>,
	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	djm@...drot.org, segoon@...nwall.com, kees.cook@...onical.com,
	rostedt@...dmis.org, fweisbec@...il.com, tglx@...utronix.de,
	Randy Dunlap <rdunlap@...otime.net>, linux-doc@...r.kernel.org,
	Eric Paris <eparis@...hat.com>,
	linux-security-module@...r.kernel.org
Subject: Re: [PATCH v9 05/13] seccomp_filter: Document what seccomp_filter is
 and how it works.

On Tue, Jul 5, 2011 at 4:50 AM, Ingo Molnar <mingo@...e.hu> wrote:
>
> * Will Drewry <wad@...omium.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.


My connectivity it a bit limiting right now, but I'll go think through
what we've discussed in these threads and what you propose here and
see if I can chart out a path that makes sense to me, or if there are
pieces I just can't resolve.  I'll follow up soon-ish.

My main concerns at this point center around making sure that whatever
solution results still implements the original goal of the patch set
-- to reduce the attack surface of the kernel in a reliable way.
Having a robust plan will help there, I hope, and give others
something to provide constructive feedback on.  Also, I'd much prefer
to be making progress on this sooner rather than waiting until October
just to figure out where to begin.  As is, I'm not entirely sold that
perf/ftrace event ids are the right interface*, but it does make sense
to explore it more thoroughly given their use in the event analysis in
this patch series.  Most likely, I'll be able to resolve my own
objection :)

thanks,
will


*  For instance, I can compile a filter set with __NR_unistd as the id
in the current patch series and have that compiled code work when run
without traversing a debugfs mount point.  That will just be another
area to be addressed in whatever the next solution is.
--
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/

Powered by blists - more mailing lists