Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965143AbXAWOEJ (ORCPT ); Tue, 23 Jan 2007 09:04:09 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S965140AbXAWOEJ (ORCPT ); Tue, 23 Jan 2007 09:04:09 -0500 Received: from 69-100-st.zelcom.ru ([80.92.100.69]:3952 "EHLO etherstorm.feelingofgreen.ru" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S965143AbXAWOEH (ORCPT ); Tue, 23 Jan 2007 09:04:07 -0500 Date: Tue, 23 Jan 2007 17:03:59 +0300 Message-ID: <87mz4996wg.wl@betelheise.deep.net> From: Samium Gromoff <_deepfire@feelingofgreen.ru> To: Pavel Machek Cc: Samium Gromoff <_deepfire@feelingofgreen.ru>, Valdis.Kletnieks@vt.edu, David Wagner , linux-kernel@vger.kernel.org Subject: Re: [PATCH] Undo some of the pseudo-security madness In-Reply-To: <20070123084805.GB5560@ucw.cz> References: <87r6toufpp.wl@betelheise.deep.net> <200701221520.l0MFKLdK032645@turing-police.cc.vt.edu> <871wlnq7ue.wl@betelheise.deep.net> <20070123084805.GB5560@ucw.cz> User-Agent: Wanderlust/2.15.5 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.8 (=?ISO-8859-4?Q?Shij=F2?=) APEL/10.6 Emacs/23.0.51 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI) X-Face: "P-:w!.&Hdk.h~~pT`!Q%H6;/8Cce^m&%vIn"W-SXb4h88dCgwD\_}N5:\}lowY2gxg0u^wVO*L\$C@MvBDRTmh/=,468w{W{OTc$kfq5O9Y!`pd+N}SMHrN+Gs>jXe5}}EL`cRbc0^_0cZ-}M\b~55I;Qe$1uL8M`M`82<_%CQ(GwLk."M>zBLn:-u>n,$kjH`~Uo[pH`08#\G!GVMd`%7![m9]*w5PMts4@m>=;lX41Z90N MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2527 Lines: 61 At Tue, 23 Jan 2007 08:48:07 +0000, Pavel Machek wrote: > > Are you saying that the usefulness of AS randomisation is > > overall exceeding that of MAP_FIXED, and the latter should be > > abolished? > > MAP_FIXED still works. You just have to be more careful where you map. No amount of carefulness will prevent vendors stick arbitrarily damaging values of stack and mmap base randomisation, severely reducing the usefullness of MAP_FIXED. And they actively take this freedom -- Arjan must know this first-hand. > > > > the only way to achieve this i see, is to directly setuid root > > > > the lisp system executable itself -- because the lisp code > > > > is read, compiled and executed in the process of the lisp > > > > system executable. > > > > > > If that's the only way you can see to do it, maybe you should think a > > > bit harder before making kernel hacks to do something. > > > > I want equal grounds for platforms, that`s all. > > Well, noone ever said all languages are equal. You have crappy lisp > interpreters, and you want to break kernel because you are too lazy to > fix them, and insist they must do suid in any way you choose. We won't > break kernel because lisp is misdesigned. SBCL is the most actively developed open source Common Lisp implementation, which has an optimising native compiler built in, so it is not an interpreter, and is, most certainly, not crappy. Speaking on the matter, how would you regard a patch which enhances the ELF loader with interpretation of an x86-specific e_flags bit which would mean a mandatory AS randomisation disable? this has the following properties: 1. cannot serve as a vehicle for exploitation for binaries unmarked with this flag 2. serve the application deployment cause -- abolish the need for application-specific system tweaks 3. remove the need for the ugly self-reexecution tweak people needing an absolutely unadulterated memory map have to resort to /now/, even in a non-setuid case > Pavel P.S.: Please, shrug off that C-esque center-of-the-world attitude, the fact there are thousand times as many C programmers does not automatically mean there is a free-for-all no-questions-asked licence to raise the implementation complexity bar for other languages. regards, Samium Gromoff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/