Re: [PATCH] Undo some of the pseudo-security madness

* Samium Gromoff: >> > Lisp environments can produce standalone executables >> >> If you've got a stand-alone executable, you don't need MAP_FIXED. The >> ELF loader maps the program at a fixed address anyway (at least on >> i386 and x86_64, I haven't checked others). > > Not so. > > The thing i

Re: [PATCH] Undo some of the pseudo-security madness

At Sat, 24 Feb 2007 10:51:20 +0100, Florian Weimer wrote: > > > Randomisation has nothing to do with C. In fact from a C perspective the > > compiler and linker do a lot of work to deal with ELF and loading code at > > arbitary addresses for dynamic linking and the like, not the user and > > not a

Re: [PATCH] Undo some of the pseudo-security madness

At Sat, 24 Feb 2007 10:40:51 +0100, Florian Weimer wrote: > > * Samium Gromoff: > > > Lisp environments can produce standalone executables > > If you've got a stand-alone executable, you don't need MAP_FIXED. The > ELF loader maps the program at a fixed address anyway (at least on > i386 and x8

Re: [PATCH] Undo some of the pseudo-security madness

> Randomisation has nothing to do with C. In fact from a C perspective the > compiler and linker do a lot of work to deal with ELF and loading code at > arbitary addresses for dynamic linking and the like, not the user and > not as language constructs. Perhaps the Lisp universe should wake up and >

Re: [PATCH] Undo some of the pseudo-security madness

* Samium Gromoff: > Lisp environments can produce standalone executables If you've got a stand-alone executable, you don't need MAP_FIXED. The ELF loader maps the program at a fixed address anyway (at least on i386 and x86_64, I haven't checked others). AFAIK, PolyML has recently made the switc

Re: [PATCH] Undo some of the pseudo-security madness

* Arjan van de Ven: >> No amount of carefulness will prevent vendors stick arbitrarily >> damaging values of stack and mmap base randomisation, severely reducing >> the usefullness of MAP_FIXED. > > MAP_FIXED is useful still. The only safe way is to use addresses you got > from mmap(), eg you over

Re: [PATCH] Undo some of the pseudo-security madness

> No amount of carefulness will prevent vendors stick arbitrarily > damaging values of stack and mmap base randomisation, severely reducing > the usefullness of MAP_FIXED. MAP_FIXED is useful still. The only safe way is to use addresses you got from mmap(), eg you overmap something. Anything else

Re: [PATCH] Undo some of the pseudo-security madness

> 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. If it requires MAP_FIXED I would beg to disagree. > 1. cannot serve as a vehicle for exploitation fo

Re: [PATCH] Undo some of the pseudo-security madness

At Tue, 23 Jan 2007 08:48:07 +, 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 carefulnes

Re: [PATCH] Undo some of the pseudo-security madness

Hi! > > > not "core-dumps" but "core files", in the lispspeak, but anyway. > > > > > > the reason is trivial -- if i can write programs enjoying setuid > > > privileges in C, i want to be able to do the same in Lisp. > > > > Go read up on how the XEmacs crew designed their "portable dumper", > >

Re: [PATCH] Undo some of the pseudo-security madness

Hi! > > nor will they work if the sysadmin applies a security update and glibc > > or another library changes one page in size. Or changes the stack rlimit > > or .. or .. > > Now, i figured out, there is a certain reasonable safety gap which works > for people, because the libraries depended on

Re: [PATCH] Undo some of the pseudo-security madness

At Mon, 22 Jan 2007 01:35:46 +0100, Arjan van de Ven wrote: > > > > 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 curren

Re: [PATCH] Undo some of the pseudo-security madness

At Mon, 22 Jan 2007 10:20:21 -0500, [EMAIL PROTECTED] wrote: > On Mon, 22 Jan 2007 02:23:30 +0300, Samium Gromoff said: > > > > not "core-dumps" but "core files", in the lispspeak, but anyway. > > > > the reason is trivial -- if i can write programs enjoying setuid > > privileges in C, i want to b

Re: [PATCH] Undo some of the pseudo-security madness

On Mon, 22 Jan 2007 02:23:30 +0300, Samium Gromoff said: > > not "core-dumps" but "core files", in the lispspeak, but anyway. > > the reason is trivial -- if i can write programs enjoying setuid > privileges in C, i want to be able to do the same in Lisp. Go read up on how the XEmacs crew designe

Re: [PATCH] Undo some of the pseudo-security madness

At Sun, 21 Jan 2007 19:36:27 -0500, Kyle Moffett wrote: > > On Jan 21, 2007, at 18:34:56, David Wagner wrote: > > [1] In comparison, suidperl was designed to be installed setuid- > > root, and it takes special precautions to be safe in this usage. > > (And even it has had some security vulnera

Re: [PATCH] Undo some of the pseudo-security madness

At Mon, 22 Jan 2007 01:35:46 +0100, Arjan van de Ven wrote: > > 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

Re: [PATCH] Undo some of the pseudo-security madness

David Wagner wrote: > Samium Gromoff wrote: > >[...] directly setuid root the lisp system executable itself [...] > > Like I said, that sounds like a bad idea to me. Sounds like a recipe for > privilege escalation vulnerabilities. Was the lisp system executable > really implemented to be secure

Re: [PATCH] Undo some of the pseudo-security madness

On Jan 21, 2007, at 18:34:56, David Wagner wrote: [1] In comparison, suidperl was designed to be installed setuid- root, and it takes special precautions to be safe in this usage. (And even it has had some security vulnerabilities, despite its best efforts, which illustrates how tricky this

Re: [PATCH] Undo some of the pseudo-security madness

> 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 native

Re: [PATCH] Undo some of the pseudo-security madness

Samium Gromoff wrote: >[...] directly setuid root the lisp system executable itself [...] Like I said, that sounds like a bad idea to me. Sounds like a recipe for privilege escalation vulnerabilities. Was the lisp system executable really implemented to be secure even when you make it setuid ro

Re: [PATCH] Undo some of the pseudo-security madness

David Wagner wrote: > Samium Gromoff wrote: > >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 co

Re: [PATCH] Undo some of the pseudo-security madness

Samium Gromoff wrote: >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

Re: [PATCH] Undo some of the pseudo-security madness

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

Re: [PATCH] Undo some of the pseudo-security madness

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 val

Re: [PATCH] Undo some of the pseudo-security madness

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 d

Re: [PATCH] Undo some of the pseudo-security madness

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 syst

Re: [PATCH] Undo some of the pseudo-security madness

At Sat, 20 Jan 2007 17:37:22 +0300, Samium Gromoff wrote: [snip] > So, here we have a buffer-overflow protection technique, which does not > actually protect against buffer overflows[1], breaking valid applications. > > I suggest getting rid of it. i botched it slightly: --- linux/include/linux/

[PATCH] Undo some of the pseudo-security madness

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