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 for Android: free password hash cracker in your pocket

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

Message-ID: <20110701210011.GA22171@elte.hu>
Date:	Fri, 1 Jul 2011 23:00:11 +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:

> On Fri, Jul 1, 2011 at 11:10 AM, Ingo Molnar <mingo@...e.hu> wrote:
>
> > But that's exactly my point: i consider it the right way forward 
> > because it maximizes kernel utility in the long run.
> 
> Not if it never happens.  Which is what happened with the proposals 
> from Adam and from Eric.

Well, that's what my job is as a maintainer: to tell you if i dislike 
a solution and to suggest better solutions - and here this was really 
easy to do, as you already prototyped a solution i consider (far) 
superior.

I cannot force you to do it like that, but i do have to say 'no'.

> > are not some bad side effect or quirk, they are all generic 
> > improvements we want in any case and not just for sandboxing.
> 
> I didn't say they were bad side effects or quirks.

That's a pretty important point as well.

> > You might not be interested in all of those items, you are only 
> > interested in getting the narrow feature-set you are interested 
> > in, but you sure are interested in getting sandboxing versus not 
> > getting anything at all, right?
> 
> Unfortunately, that isn't the value proposition for me or many 
> other contributors.  The real question is whether I am interested 
> in getting sandboxing in with mainline or if I want to sign up to 
> maintain the patches out of tree until my hair falls out.

Well, if you implement the right solution then why should it stay out 
of tree?

If the code is clean and useful and resolves all the technical 
objections that were raised against it then i will certainly merge it 
- and i hope Linus will chime in if he finds the actual iteration 
unacceptable and the direction harmful, to save us all the trouble.

In the end the 'sandboxing' feature should be a few dozen lines at 
most - all the rest will just be shared infrastructure.

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/