From: Samium Gromoff <_deepfire@feelingofgreen.ru>
To: Arjan van de Ven <arjan@infradead.org>
Cc: Samium Gromoff <_deepfire@feelingofgreen.ru>,
linux-kernel@vger.kernel.org, David Wagner <daw@cs.berkeley.edu>
Subject: Re: [PATCH] Undo some of the pseudo-security madness
Date: Mon, 22 Jan 2007 01:09:58 +0300 [thread overview]
Message-ID: <87tzykuj49.wl@betelheise.deep.net> (raw)
In-Reply-To: <1169345764.3055.935.camel@laptopd505.fenrus.org>
At Sun, 21 Jan 2007 03:16:04 +0100,
Arjan van de Ven wrote:
>
> On Sat, 2007-01-20 at 17:37 +0300, Samium Gromoff wrote:
> > This patch removes the dropping of ADDR_NO_RANDOMIZE upon execution of setuid
> > binaries.
> >
> > Why? The answer consists of two parts:
> >
> > Firstly, there are valid applications which need an unadulterated memory map.
> > Some of those which do their memory management, like lisp systems (like SBCL).
> > They try to achieve this by setting ADDR_NO_RANDOMIZE and reexecuting themselves.
>
> this is a ... funny way of achieving this
>
> if an application for some reason wants some fixed address for a piece
> of memory there are other ways to do that.... (but to some degree all
> apps that can't take randomization broken; for example a glibc upgrade
> on a system will also move the address space around by virtue of being
> bigger or smaller etc etc)
the core of the problem are the cores which are customarily
dumped by lisps during the environment generation (or modification) stage,
and then mapped back, every time the environment is invoked.
at the current step of evolution, those core files are not relocatable
in certain natively compiling lisp systems.
in an even smaller subset of them, these cores are placed after
the shared libraries and the executable.
which obviously breaks when the latter are placed unpredictably.
(yes, i know, currently mmap_base() varies over a 1MB range, but who
says it will last indefinitely -- probably one day these people
from full-disclosure will prevail and it will become, like, 256MB ;-)
so, what do you propose?
regards, Samium Gromoff
next prev parent reply other threads:[~2007-01-21 22:10 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-20 14:37 [PATCH] Undo some of the pseudo-security madness Samium Gromoff
2007-01-20 16:12 ` Samium Gromoff
2007-01-20 21:58 ` David Wagner
2007-01-21 2:16 ` Arjan van de Ven
2007-01-21 21:38 ` Samium Gromoff
2007-01-21 22:09 ` Samium Gromoff [this message]
2007-01-21 22:16 ` David Wagner
2007-01-22 0:35 ` Arjan van de Ven
2007-01-22 1:15 ` Samium Gromoff
2007-01-22 17:52 ` Samium Gromoff
2007-01-23 8:44 ` Pavel Machek
-- strict thread matches above, loose matches on Subject: below --
2007-01-21 23:23 Samium Gromoff
2007-01-21 23:34 ` David Wagner
2007-01-22 0:36 ` Kyle Moffett
2007-01-22 1:53 ` Samium Gromoff
2007-02-24 9:40 ` Florian Weimer
2007-02-24 13:33 ` Samium Gromoff
2007-02-24 13:49 ` Florian Weimer
2007-01-22 15:20 ` Valdis.Kletnieks
2007-01-22 17:39 ` Samium Gromoff
2007-01-23 8:48 ` Pavel Machek
2007-01-23 14:03 ` Samium Gromoff
2007-01-23 15:41 ` Alan
2007-02-24 9:51 ` Florian Weimer
2007-02-24 13:36 ` Samium Gromoff
2007-01-31 9:59 ` Arjan van de Ven
2007-02-01 8:05 ` Florian Weimer
2007-01-22 0:54 Samium Gromoff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tzykuj49.wl@betelheise.deep.net \
--to=_deepfire@feelingofgreen.ru \
--cc=arjan@infradead.org \
--cc=daw@cs.berkeley.edu \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox