linux-kernel - Re: [PATCH v9 05/13] seccomp_filter: Document what 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]

Message-ID: <20110705095019.GC5725@elte.hu>
Date:	Tue, 5 Jul 2011 11:50:19 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Will Drewry <wad@...omium.org>
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.


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

Thanks,

	Ingo
--
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/