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

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

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

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

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

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

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 x86_64, 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 as

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 is that the

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

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 overmap

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

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

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

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

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 are well

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, specifically to get

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 carefulness will

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 for

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

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

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

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 designed their

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 be able to do

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 of

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

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

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

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

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

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

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

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

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 valid

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 valid

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

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 core files

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

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 natively

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

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 even

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 of

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

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

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

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

[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

[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

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

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 systems

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 do