LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Re: [PATCH] Undo some of the pseudo-security madness
@ 2007-01-21 23:23 Samium Gromoff
  2007-01-21 23:34 ` David Wagner
  2007-01-22 15:20 ` Valdis.Kletnieks
  0 siblings, 2 replies; 38+ messages in thread
From: Samium Gromoff @ 2007-01-21 23:23 UTC (permalink / raw)
  To: David Wagner; +Cc: linux-kernel

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 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?
> 
> The obvious solution is: Don't make them setuid root.
> Then this issue disappears.
> 
> If there is some strong reason why they need to be setuid root, then
> you'll need to explain that reason and your requirements in more detail.
> But, based on your explanation so far, I have serious doubts about
> whether it is a good idea to make such core-dumps setuid root in the
> first place.

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.

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.

there is such a thing as suid-perl -- for precise same reasons.

regards, Samium Gromoff

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] Undo some of the pseudo-security madness
  2007-01-21 23:23 [PATCH] Undo some of the pseudo-security madness Samium Gromoff
@ 2007-01-21 23:34 ` David Wagner
  2007-01-22  0:36   ` Kyle Moffett
  2007-01-22 15:20 ` Valdis.Kletnieks
  1 sibling, 1 reply; 38+ messages in thread
From: David Wagner @ 2007-01-21 23:34 UTC (permalink / raw)
  To: linux-kernel

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 root?
Setting the setuid-root bit on programs that didn't expect to be
setuid-root is generally not a very safe thing to do. [1]

The more I hear, the more unconvinced I am by this use case.

If you don't care about the security issues created by (mis)using the lisp
interpreter in this way, then like I suggested before, you can always
write a tiny setuid-root wrapper program that turns off address space
randomization and exec()s the lisp system executable, and leave the lisp
system executable non-setuid and don't touch the code in the Linux kernel.
That strikes me as a better solution: those who don't mind the security
risks can take all the risks they want, without forcing others to take
unwanted and unnecessary risks.

It's not that I'm wedded to address space randomization of setuid
programs, or that I think it would be a disaster if this patch were
accepted.  Local privilege escalation attacks aren't the end of the world;
in all honesty, they're pretty much irrelevant to many or most users.
It's just that the arguments I'm hearing advanced in support of this
change seem dubious, and the change does eliminate one of the defenses
against a certain (narrow) class of attacks.


[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 business can be.)  Setting the setuid-root
bit on a large complex interpreter that wasn't designed to be setuid-root
seems like a pretty dubious proposition to me.

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] Undo some of the pseudo-security madness
  2007-01-21 23:34 ` David Wagner
@ 2007-01-22  0:36   ` Kyle Moffett
  2007-01-22  1:53     ` Samium Gromoff
  0 siblings, 1 reply; 38+ messages in thread
From: Kyle Moffett @ 2007-01-22  0:36 UTC (permalink / raw)
  To: David Wagner; +Cc: LKML Kernel, Samium Gromoff

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 business can be.)   
> Setting the setuid-root bit on a large complex interpreter that  
> wasn't designed to be setuid-root seems like a pretty dubious  
> proposition to me.

Well, there's also the fact that Linux does *NOT* need suidperl, as  
it has proper secure support for suid pound-bang scripts anyways.   
The only reason for suidperl in the first place was broken operating  
systems which had a race condition between the operating system  
checking the suid bits and reading the '#! /usr/bin/perl' line in the  
file, and the interpreter getting executed and opening a different  
file (think symlink redirection attacks).  I believe Linux jumps  
through some special hoops to ensure that can't happen.

Cheers,
Kyle Moffett


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] Undo some of the pseudo-security madness
  2007-01-22  0:36   ` Kyle Moffett
@ 2007-01-22  1:53     ` Samium Gromoff
  2007-02-24  9:40       ` Florian Weimer
  0 siblings, 1 reply; 38+ messages in thread
From: Samium Gromoff @ 2007-01-22  1:53 UTC (permalink / raw)
  To: Kyle Moffett; +Cc: David Wagner, LKML Kernel, Samium Gromoff

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 vulnerabilities, despite its  
> > best efforts, which illustrates how tricky this business can be.)   
> > Setting the setuid-root bit on a large complex interpreter that  
> > wasn't designed to be setuid-root seems like a pretty dubious  
> > proposition to me.
> 
> Well, there's also the fact that Linux does *NOT* need suidperl, as  
> it has proper secure support for suid pound-bang scripts anyways.   
> The only reason for suidperl in the first place was broken operating  
> systems which had a race condition between the operating system  
> checking the suid bits and reading the '#! /usr/bin/perl' line in the  
> file, and the interpreter getting executed and opening a different  
> file (think symlink redirection attacks).  I believe Linux jumps  
> through some special hoops to ensure that can't happen.

Uh, this does not work, unfortunately in the Lisp case.

Lisp environments can produce standalone executables, which are

1. supposed to be runnable like a usual binary, without any additions
2. will suffer from the very same problem, as it merely is a
runtime bundled with the core file

(and the core file is unrelocatable)

> Kyle Moffett

regards, Samium Gromoff

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] Undo some of the pseudo-security madness
  2007-01-21 23:23 [PATCH] Undo some of the pseudo-security madness Samium Gromoff
  2007-01-21 23:34 ` David Wagner
@ 2007-01-22 15:20 ` Valdis.Kletnieks
  2007-01-22 17:39   ` Samium Gromoff
  1 sibling, 1 reply; 38+ messages in thread
From: Valdis.Kletnieks @ 2007-01-22 15:20 UTC (permalink / raw)
  To: Samium Gromoff; +Cc: David Wagner, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 784 bytes --]

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 "portable dumper",
specifically to get around a lot of these sorts of problems because the
old Emacs 'unexec' code was incredibly fragile.

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





[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] Undo some of the pseudo-security madness
  2007-01-22 15:20 ` Valdis.Kletnieks
@ 2007-01-22 17:39   ` Samium Gromoff
  2007-01-23  8:48     ` Pavel Machek
  0 siblings, 1 reply; 38+ messages in thread
From: Samium Gromoff @ 2007-01-22 17:39 UTC (permalink / raw)
  To: Valdis.Kletnieks; +Cc: Samium Gromoff, David Wagner, linux-kernel

At Mon, 22 Jan 2007 10:20:21 -0500,
Valdis.Kletnieks@vt.edu 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 the same in Lisp.
> 
> Go read up on how the XEmacs crew designed their "portable dumper",
> specifically to get around a lot of these sorts of problems because the
> old Emacs 'unexec' code was incredibly fragile.

I should take the freedom to respond in your manner :-)

Are you saying that the usefulness of AS randomisation is
overall exceeding that of MAP_FIXED, and the latter should be
abolished?

Did we silently enter an era where support for buggy software
is more important than a basic mmap feature?

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

regards, Samium Gromoff

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] Undo some of the pseudo-security madness
  2007-01-22 17:39   ` Samium Gromoff
@ 2007-01-23  8:48     ` Pavel Machek
  2007-01-23 14:03       ` Samium Gromoff
  0 siblings, 1 reply; 38+ messages in thread
From: Pavel Machek @ 2007-01-23  8:48 UTC (permalink / raw)
  To: Samium Gromoff; +Cc: Valdis.Kletnieks, David Wagner, linux-kernel

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 around a lot of these sorts of problems because the
> > old Emacs 'unexec' code was incredibly fragile.
> 
> I should take the freedom to respond in your manner :-)
> 
> 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.

> > > 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.
							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] Undo some of the pseudo-security madness
  2007-01-23  8:48     ` Pavel Machek
@ 2007-01-23 14:03       ` Samium Gromoff
  2007-01-23 15:41         ` Alan
  2007-01-31  9:59         ` Arjan van de Ven
  0 siblings, 2 replies; 38+ messages in thread
From: Samium Gromoff @ 2007-01-23 14:03 UTC (permalink / raw)
  To: Pavel Machek; +Cc: Samium Gromoff, Valdis.Kletnieks, David Wagner, linux-kernel

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

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] Undo some of the pseudo-security madness
  2007-01-23 14:03       ` Samium Gromoff
@ 2007-01-23 15:41         ` Alan
  2007-01-23 20:21           ` [PATCH 0/2] Mechanism to turn of ASR on a per-ELF binary basis Samium Gromoff
                             ` (3 more replies)
  2007-01-31  9:59         ` Arjan van de Ven
  1 sibling, 4 replies; 38+ messages in thread
From: Alan @ 2007-01-23 15:41 UTC (permalink / raw)
  To: Samium Gromoff
  Cc: Pavel Machek, Samium Gromoff, Valdis.Kletnieks, David Wagner,
	linux-kernel

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

Seems sensible to me. If you specifically need that mapping behaviour and
ask for it then it wouldn't be hard to provide.

> Please, shrug off that C-esque center-of-the-world attitude,
> the fact there are thousand times as many C programmers does not

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
meet the 1980s 8)


Alan

^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 0/2] Mechanism to turn of ASR on a per-ELF binary basis
  2007-01-23 15:41         ` Alan
@ 2007-01-23 20:21           ` Samium Gromoff
  2007-01-23 20:28           ` [PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit Samium Gromoff
                             ` (2 subsequent siblings)
  3 siblings, 0 replies; 38+ messages in thread
From: Samium Gromoff @ 2007-01-23 20:21 UTC (permalink / raw)
  To: Alan
  Cc: Samium Gromoff, Pavel Machek, Valdis.Kletnieks, David Wagner,
	linux-kernel

These patches allow the binaries which absolutely require that
their address space layout to be unaffected by address space
randomisation to specify that in their ELF header.

The first part defines the ELF header flag, the second implements
the corresponding part of the interpreter functionality.

regards, Samium Gromoff

^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit
  2007-01-23 15:41         ` Alan
  2007-01-23 20:21           ` [PATCH 0/2] Mechanism to turn of ASR on a per-ELF binary basis Samium Gromoff
@ 2007-01-23 20:28           ` Samium Gromoff
  2007-01-23 20:50             ` Jakub Jelinek
  2007-01-29  1:18             ` Arjan van de Ven
  2007-01-23 20:31           ` [PATCH 2/2] Make the EF_AS_NO_RANDOM e_flag bit disable PF_RANDOMIZE Samium Gromoff
  2007-02-24  9:51           ` [PATCH] Undo some of the pseudo-security madness Florian Weimer
  3 siblings, 2 replies; 38+ messages in thread
From: Samium Gromoff @ 2007-01-23 20:28 UTC (permalink / raw)
  To: Alan
  Cc: Samium Gromoff, Pavel Machek, Valdis.Kletnieks, David Wagner,
	linux-kernel

Author: Samium Gromoff <deepfire@betelheise.deep.net>
Date:   Tue Jan 23 22:31:13 2007 +0300

    Define the ELF binary header flag EF_AS_NO_RANDOM
    
    EF_AS_NO_RANDOM should mean that the binary requests to not apply
    randomisation to address spaces of its processes.

diff --git a/include/linux/elf.h b/include/linux/elf.h
index 60713e6..58ebb47 100644
--- a/include/linux/elf.h
+++ b/include/linux/elf.h
@@ -172,6 +172,8 @@ typedef struct elf64_sym {
 
 #define EI_NIDENT      16
 
+#define EF_AS_NO_RANDOM 0x1    /* do not randomise the address space */
+
 typedef struct elf32_hdr{
   unsigned char        e_ident[EI_NIDENT];
   Elf32_Half   e_type;

^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH 2/2] Make the EF_AS_NO_RANDOM e_flag bit disable PF_RANDOMIZE
  2007-01-23 15:41         ` Alan
  2007-01-23 20:21           ` [PATCH 0/2] Mechanism to turn of ASR on a per-ELF binary basis Samium Gromoff
  2007-01-23 20:28           ` [PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit Samium Gromoff
@ 2007-01-23 20:31           ` Samium Gromoff
  2007-02-24  9:51           ` [PATCH] Undo some of the pseudo-security madness Florian Weimer
  3 siblings, 0 replies; 38+ messages in thread
From: Samium Gromoff @ 2007-01-23 20:31 UTC (permalink / raw)
  To: Alan
  Cc: Samium Gromoff, Pavel Machek, Valdis.Kletnieks, David Wagner,
	linux-kernel

Author: Samium Gromoff <deepfire@betelheise.deep.net>
Date:   Tue Jan 23 23:12:16 2007 +0300

    load_elf_binary: do not set PF_RANDOMIZE if the ELF file has EF_AS_NO_RANDOM s
et

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 7cb2872..007dedd 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -780,7 +780,8 @@ static int load_elf_binary(struct linux_binprm *bprm, struct p
t_regs *regs)
        if (elf_read_implies_exec(loc->elf_ex, executable_stack))
                current->personality |= READ_IMPLIES_EXEC;
 
-       if (!(current->personality & ADDR_NO_RANDOMIZE) && randomize_va_space)
+       if (!(current->personality & ADDR_NO_RANDOMIZE) &&
+           !(loc->elf_ex.e_flags & EF_AS_NO_RANDOM) && randomize_va_space)
                current->flags |= PF_RANDOMIZE;
        arch_pick_mmap_layout(current->mm);

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit
  2007-01-23 20:28           ` [PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit Samium Gromoff
@ 2007-01-23 20:50             ` Jakub Jelinek
  2007-01-23 21:06               ` Samium Gromoff
  2007-01-29  1:18             ` Arjan van de Ven
  1 sibling, 1 reply; 38+ messages in thread
From: Jakub Jelinek @ 2007-01-23 20:50 UTC (permalink / raw)
  To: Samium Gromoff
  Cc: Alan, Pavel Machek, Valdis.Kletnieks, David Wagner, linux-kernel

On Tue, Jan 23, 2007 at 11:28:13PM +0300, Samium Gromoff wrote:
> Author: Samium Gromoff <deepfire@betelheise.deep.net>
> Date:   Tue Jan 23 22:31:13 2007 +0300
> 
>     Define the ELF binary header flag EF_AS_NO_RANDOM
>     
>     EF_AS_NO_RANDOM should mean that the binary requests to not apply
>     randomisation to address spaces of its processes.
> 
> diff --git a/include/linux/elf.h b/include/linux/elf.h
> index 60713e6..58ebb47 100644
> --- a/include/linux/elf.h
> +++ b/include/linux/elf.h
> @@ -172,6 +172,8 @@ typedef struct elf64_sym {
>  
>  #define EI_NIDENT      16
>  
> +#define EF_AS_NO_RANDOM 0x1    /* do not randomise the address space */
> +

You can't make up EF_* flags this way, they are arch specific, the LSB bit
(but many others too) are already used on many architectures.
E.g.:
elf/mt.h:#define EF_MT_CPU_MRISC              0x00000001      /* default */
elf/sparc.h:#define EF_SPARCV9_PSO            0x1             /* partial store ordering */
elf/bfin.h:#define EF_BFIN_PIC                0x00000001      /* -fpic */
elf/alpha.h:#define EF_ALPHA_32BIT            0x00000001
elf/mips.h:#define EF_MIPS_NOREORDER  0x00000001
elf/m68k.h:#define EF_M68K_CF_ISA_A_NODIV     0x01  /* ISA A except for div */
elf/sh.h:#define EF_SH1                  1
elf/arm.h:#define EF_ARM_RELEXEC     0x01
elf/cris.h:#define EF_CRIS_UNDERSCORE         0x00000001
elf/ia64.h:#define EF_IA_64_TRAPNIL (1 << 0)  /* Trap NIL pointer dereferences.  */
elf/vax.h:#define EF_VAX_NONPIC               0x0001  /* Object contains non-PIC code */
elf/iq2000.h:#define EF_IQ2000_CPU_IQ2000     0x00000001      /* default */
elf/frv.h:#define EF_FRV_GPR_32               0x00000001      /* -mgpr-32 */
to name just a few.

	Jakub

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit
  2007-01-23 20:50             ` Jakub Jelinek
@ 2007-01-23 21:06               ` Samium Gromoff
  2007-01-23 21:16                 ` Jakub Jelinek
  0 siblings, 1 reply; 38+ messages in thread
From: Samium Gromoff @ 2007-01-23 21:06 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Samium Gromoff, Alan, linux-kernel

At Tue, 23 Jan 2007 15:50:18 -0500,
Jakub Jelinek wrote:
> 
> On Tue, Jan 23, 2007 at 11:28:13PM +0300, Samium Gromoff wrote:
> > Author: Samium Gromoff <deepfire@betelheise.deep.net>
> > Date:   Tue Jan 23 22:31:13 2007 +0300
> > 
> >     Define the ELF binary header flag EF_AS_NO_RANDOM
> >     
> >     EF_AS_NO_RANDOM should mean that the binary requests to not apply
> >     randomisation to address spaces of its processes.
> > 
> > diff --git a/include/linux/elf.h b/include/linux/elf.h
> > index 60713e6..58ebb47 100644
> > --- a/include/linux/elf.h
> > +++ b/include/linux/elf.h
> > @@ -172,6 +172,8 @@ typedef struct elf64_sym {
> >  
> >  #define EI_NIDENT      16
> >  
> > +#define EF_AS_NO_RANDOM 0x1    /* do not randomise the address space */
> > +
> 
> You can't make up EF_* flags this way, they are arch specific, the LSB bit
> (but many others too) are already used on many architectures.
> E.g.:
> elf/mt.h:#define EF_MT_CPU_MRISC              0x00000001      /* default */
> elf/sparc.h:#define EF_SPARCV9_PSO            0x1             /* partial store ordering */
> elf/bfin.h:#define EF_BFIN_PIC                0x00000001      /* -fpic */
> elf/alpha.h:#define EF_ALPHA_32BIT            0x00000001
> elf/mips.h:#define EF_MIPS_NOREORDER  0x00000001
> elf/m68k.h:#define EF_M68K_CF_ISA_A_NODIV     0x01  /* ISA A except for div */
> elf/sh.h:#define EF_SH1                  1
> elf/arm.h:#define EF_ARM_RELEXEC     0x01
> elf/cris.h:#define EF_CRIS_UNDERSCORE         0x00000001
> elf/ia64.h:#define EF_IA_64_TRAPNIL (1 << 0)  /* Trap NIL pointer dereferences.  */
> elf/vax.h:#define EF_VAX_NONPIC               0x0001  /* Object contains non-PIC code */
> elf/iq2000.h:#define EF_IQ2000_CPU_IQ2000     0x00000001      /* default */
> elf/frv.h:#define EF_FRV_GPR_32               0x00000001      /* -mgpr-32 */
> to name just a few.

Should we introduce per-arch asm/elf.h files to hold the relevant flag definitions then?

> 	Jakub

regards, Samium Gromoff

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit
  2007-01-23 21:06               ` Samium Gromoff
@ 2007-01-23 21:16                 ` Jakub Jelinek
  2007-01-23 21:54                   ` Samium Gromoff
  2007-01-23 23:21                   ` Samium Gromoff
  0 siblings, 2 replies; 38+ messages in thread
From: Jakub Jelinek @ 2007-01-23 21:16 UTC (permalink / raw)
  To: Samium Gromoff; +Cc: Alan, linux-kernel

On Wed, Jan 24, 2007 at 12:06:45AM +0300, Samium Gromoff wrote:
> Should we introduce per-arch asm/elf.h files to hold the relevant flag definitions then?

On some architectures there are no bits left.  On others you'd need to go
through whomever maintains the relevant psABI to get a bit officially
allocated.  Really, it is very bad idea to use e_flags for this.

If all you care about is running setuid LISP programs, you'd much better put
your energy into fixing the buggy ELF dumper in it.

	Jakub

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit
  2007-01-23 21:16                 ` Jakub Jelinek
@ 2007-01-23 21:54                   ` Samium Gromoff
  2007-01-23 23:21                   ` Samium Gromoff
  1 sibling, 0 replies; 38+ messages in thread
From: Samium Gromoff @ 2007-01-23 21:54 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Samium Gromoff, Alan, linux-kernel

At Tue, 23 Jan 2007 16:16:12 -0500,
Jakub Jelinek wrote:
> 
> On Wed, Jan 24, 2007 at 12:06:45AM +0300, Samium Gromoff wrote:
> > Should we introduce per-arch asm/elf.h files to hold the relevant flag definitions then?
> 
> On some architectures there are no bits left.  On others you'd need to go
> through whomever maintains the relevant psABI to get a bit officially
> allocated.  Really, it is very bad idea to use e_flags for this.

Currently arch_align_stack() and mmap_base() perform randomisation only on x86
and x86_64, so it is only two architectures anyway...

> If all you care about is running setuid LISP programs, you'd much better put
> your energy into fixing the buggy ELF dumper in it.
> 
> 	Jakub

regards, Samium Gromoff

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit
  2007-01-23 21:16                 ` Jakub Jelinek
  2007-01-23 21:54                   ` Samium Gromoff
@ 2007-01-23 23:21                   ` Samium Gromoff
  2007-01-24 17:08                     ` Pavel Machek
  1 sibling, 1 reply; 38+ messages in thread
From: Samium Gromoff @ 2007-01-23 23:21 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Samium Gromoff, Alan, linux-kernel

At Tue, 23 Jan 2007 16:16:12 -0500,
Jakub Jelinek wrote:
> 
> On Wed, Jan 24, 2007 at 12:06:45AM +0300, Samium Gromoff wrote:
> > Should we introduce per-arch asm/elf.h files to hold the relevant flag definitions then?
> 
> On some architectures there are no bits left.  On others you'd need to go
> through whomever maintains the relevant psABI to get a bit officially
> allocated.  Really, it is very bad idea to use e_flags for this.

How does one find the relevant maintainers?

Even just the specs are harder to find in the authoritative location,
given the OSDL and FSG merge: the psabi documents at

http://www.linux-foundation.org/spec/refspecs/

all 404...
 
> If all you care about is running setuid LISP programs, you'd much better put
> your energy into fixing the buggy ELF dumper in it.
> 
> 	Jakub

regards, Samium Gromoff

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit
  2007-01-23 23:21                   ` Samium Gromoff
@ 2007-01-24 17:08                     ` Pavel Machek
  0 siblings, 0 replies; 38+ messages in thread
From: Pavel Machek @ 2007-01-24 17:08 UTC (permalink / raw)
  To: Samium Gromoff; +Cc: Jakub Jelinek, Alan, linux-kernel

Hi!

> > > Should we introduce per-arch asm/elf.h files to hold the relevant flag definitions then?
> > 
> > On some architectures there are no bits left.  On others you'd need to go
> > through whomever maintains the relevant psABI to get a bit officially
> > allocated.  Really, it is very bad idea to use e_flags for this.
> 
> How does one find the relevant maintainers?

Andi Kleen maintains both i386 and x86-64, so it should be easy.

(Ouch and make it one patch, it is too short to split...)

							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit
  2007-01-23 20:28           ` [PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit Samium Gromoff
  2007-01-23 20:50             ` Jakub Jelinek
@ 2007-01-29  1:18             ` Arjan van de Ven
  1 sibling, 0 replies; 38+ messages in thread
From: Arjan van de Ven @ 2007-01-29  1:18 UTC (permalink / raw)
  To: Samium Gromoff
  Cc: Alan, Pavel Machek, Valdis.Kletnieks, David Wagner, linux-kernel

On Tue, 2007-01-23 at 23:28 +0300, Samium Gromoff wrote:
> Author: Samium Gromoff <deepfire@betelheise.deep.net>
> Date:   Tue Jan 23 22:31:13 2007 +0300
> 
>     Define the ELF binary header flag EF_AS_NO_RANDOM
>     
>     EF_AS_NO_RANDOM should mean that the binary requests to not apply
>     randomisation to address spaces of its processes.

sounds like it's not the right approach; better to follow the
PT_GNU_STACK example and do it that way.....

(assuming you even need it... I personally consider every binary that
would need this flag as broken)


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] Undo some of the pseudo-security madness
  2007-01-23 14:03       ` Samium Gromoff
  2007-01-23 15:41         ` Alan
@ 2007-01-31  9:59         ` Arjan van de Ven
  2007-02-01  8:05           ` Florian Weimer
  1 sibling, 1 reply; 38+ messages in thread
From: Arjan van de Ven @ 2007-01-31  9:59 UTC (permalink / raw)
  To: Samium Gromoff; +Cc: Pavel Machek, Valdis.Kletnieks, David Wagner, linux-kernel


> 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 is madness, with or without randomization. The C library
for example is free, and does, allocate memory and stacks etc etc.

Same for many other libraries; in addition libraries change in size all
the time... MAP_FIXED of an address you don't KNOW is free is a bug.
Period.
(using an address previously obtained from mmap() is safest, but you
could in theory also parse /proc/self/maps, although that is racey,
since nothing guarantees that the C library didn't spawn a background
thread that allocates memory)



^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] Undo some of the pseudo-security madness
  2007-01-31  9:59         ` Arjan van de Ven
@ 2007-02-01  8:05           ` Florian Weimer
  0 siblings, 0 replies; 38+ messages in thread
From: Florian Weimer @ 2007-02-01  8:05 UTC (permalink / raw)
  To: Arjan van de Ven
  Cc: Samium Gromoff, Pavel Machek, Valdis.Kletnieks, David Wagner,
	linux-kernel

* 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 something.
> Anything else is madness, with or without randomization. The C library
> for example is free, and does, allocate memory and stacks etc etc.

This reminds me of a different matter: What is the recommended way to
reserve address space (so that libc etc. won't use it) *without*
increasing the VM committed memory counter?  In other words, without
allocating backing store for it?

IIRC, mmap(PROT_NONE) followed by mprotect(PROT_READ | PROT_WRITE)
seems to work, but I wonder if this is just an accident, or if this is
part of the API.

This is an interesting topic because such functionality is required to
make many virtual machines work with address space randomization and
(especially) vm.overcommit_memory=2.  They don't need the backing
store from the beginning, but they really like (if not need, even)
huge regions of continuous address space.

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] Undo some of the pseudo-security madness
  2007-01-22  1:53     ` Samium Gromoff
@ 2007-02-24  9:40       ` Florian Weimer
  2007-02-24 13:33         ` Samium Gromoff
  0 siblings, 1 reply; 38+ messages in thread
From: Florian Weimer @ 2007-02-24  9:40 UTC (permalink / raw)
  To: Samium Gromoff; +Cc: Kyle Moffett, David Wagner, LKML Kernel

* 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 switch to stand-alone executables
for this reason.

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] Undo some of the pseudo-security madness
  2007-01-23 15:41         ` Alan
                             ` (2 preceding siblings ...)
  2007-01-23 20:31           ` [PATCH 2/2] Make the EF_AS_NO_RANDOM e_flag bit disable PF_RANDOMIZE Samium Gromoff
@ 2007-02-24  9:51           ` Florian Weimer
  2007-02-24 13:36             ` Samium Gromoff
  3 siblings, 1 reply; 38+ messages in thread
From: Florian Weimer @ 2007-02-24  9:51 UTC (permalink / raw)
  To: Alan
  Cc: Samium Gromoff, Pavel Machek, Valdis.Kletnieks, David Wagner,
	linux-kernel

> 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
> meet the 1980s 8)

Uhm, C++ folks and others have run into loader performance issues due
to the way DSOs are handled.  The problem is more severe in the lisp
context because a typical image contains hundreds of thousands of
small objects on startup.

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] Undo some of the pseudo-security madness
  2007-02-24  9:40       ` Florian Weimer
@ 2007-02-24 13:33         ` Samium Gromoff
  2007-02-24 13:49           ` Florian Weimer
  0 siblings, 1 reply; 38+ messages in thread
From: Samium Gromoff @ 2007-02-24 13:33 UTC (permalink / raw)
  To: Florian Weimer; +Cc: Samium Gromoff, Kyle Moffett, David Wagner, LKML Kernel

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 haven't checked others).

Not so.

The thing is that the picture is of two pieces:

 - the executable
 - the unrelocatable lisp core (which is unrelocatable by the virtue
   of non-PIC code) which is mapped into the AS of the executable.

It is the latter which breaks, as its map can overlap with randomized
pieces of the executable (along with its libraries).

> AFAIK, PolyML has recently made the switch to stand-alone executables
> for this reason.

regards, Samium Gromoff

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] Undo some of the pseudo-security madness
  2007-02-24  9:51           ` [PATCH] Undo some of the pseudo-security madness Florian Weimer
@ 2007-02-24 13:36             ` Samium Gromoff
  0 siblings, 0 replies; 38+ messages in thread
From: Samium Gromoff @ 2007-02-24 13:36 UTC (permalink / raw)
  To: Florian Weimer
  Cc: Alan, Samium Gromoff, Pavel Machek, Valdis.Kletnieks,
	David Wagner, linux-kernel

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 language constructs. Perhaps the Lisp universe should wake up and
> > meet the 1980s 8)
> 
> Uhm, C++ folks and others have run into loader performance issues due
> to the way DSOs are handled.  The problem is more severe in the lisp
> context because a typical image contains hundreds of thousands of
> small objects on startup.

Well:

root@betelheise:/mnt/shared/video1 # cat /proc/`pgrep sbcl | head -n1`/maps | wc -l
1378

regards, Samium Gromoff

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] Undo some of the pseudo-security madness
  2007-02-24 13:33         ` Samium Gromoff
@ 2007-02-24 13:49           ` Florian Weimer
  0 siblings, 0 replies; 38+ messages in thread
From: Florian Weimer @ 2007-02-24 13:49 UTC (permalink / raw)
  To: Samium Gromoff; +Cc: Kyle Moffett, David Wagner, LKML Kernel

* 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 picture is of two pieces:
>
>  - the executable
>  - the unrelocatable lisp core (which is unrelocatable by the virtue
>    of non-PIC code) which is mapped into the AS of the executable.
>
> It is the latter which breaks, as its map can overlap with randomized
> pieces of the executable (along with its libraries).

I think it boils down to the question if you can use ELF relocations
to create a relocatable (but not necessarily position-independent)
object that ld can link with the SBCL run-time system to produce an
executable.  This executable would truly be stand-alone because no
separate core file is required anymore.

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] Undo some of the pseudo-security madness
  2007-01-22 17:52       ` Samium Gromoff
@ 2007-01-23  8:44         ` Pavel Machek
  0 siblings, 0 replies; 38+ messages in thread
From: Pavel Machek @ 2007-01-23  8:44 UTC (permalink / raw)
  To: Samium Gromoff; +Cc: Arjan van de Ven, linux-kernel, David Wagner

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 known.
> 
> What happens with AS randomisation, is that the variance is simply too
> large. But what is more important, is that vendors do modifications
> which change the amount of randomisation, which means that potentially

Complain to vendors, not here.

							Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] Undo some of the pseudo-security madness
  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
  1 sibling, 1 reply; 38+ messages in thread
From: Samium Gromoff @ 2007-01-22 17:52 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: Samium Gromoff, linux-kernel, David Wagner

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 evolution, those core files are not relocatable
> > in certain natively compiling lisp systems.
> 
> 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 known.

What happens with AS randomisation, is that the variance is simply too
large. But what is more important, is that vendors do modifications
which change the amount of randomisation, which means that potentially
no MAP_FIXED is safe, generally.

Yes, there is uncertainty in both cases -- library variance or AS randomisation,
but the latter arguably crosses a practical manageability boundary.

> -- 
> if you want to mail me at work (you don't), use arjan (at) linux.intel.com
> Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

regards, Samium Gromoff

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] Undo some of the pseudo-security madness
  2007-01-22  0:35     ` Arjan van de Ven
@ 2007-01-22  1:15       ` Samium Gromoff
  2007-01-22 17:52       ` Samium Gromoff
  1 sibling, 0 replies; 38+ messages in thread
From: Samium Gromoff @ 2007-01-22  1:15 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: Samium Gromoff, linux-kernel, David Wagner

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 evolution, those core files are not relocatable
> > in certain natively compiling lisp systems.
> 
> 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 ..

At this point i should just step down and declare incompetence --
SBCL works around shlib size variance, somehow, and /yet/ the whole
turn-off-AS-randomisation-and-reexec-self thing is still present in the source,
for some reason.

I should let more competent people (read, the actual SBCL developers)
take the way from now...

(I could have digged the source myself, but it is way too late today.
However, if nobody from the development team answers by tomorrow`s evening (gmt+3),
i should see into the thing for myself).

> -- 
> if you want to mail me at work (you don't), use arjan (at) linux.intel.com
> Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

regards, Samium Gromoff

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] Undo some of the pseudo-security madness
@ 2007-01-22  0:54 Samium Gromoff
  0 siblings, 0 replies; 38+ messages in thread
From: Samium Gromoff @ 2007-01-22  0:54 UTC (permalink / raw)
  To: David Wagner; +Cc: linux-kernel

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 when you make it setuid root?
> Setting the setuid-root bit on programs that didn't expect to be
> setuid-root is generally not a very safe thing to do. [1]

1. Unsafe setuid programs have been written, and they doubtlessly
will continue to be written.

2. Lisp systems are written by extremely competent people.
(who make mistakes nonetheless, but still..)

3. I think that the ability to choose whether or not to shoot oneself
in the foot is an important freedom.

4. The whole issue is a little bit unfair, because the UNIX world
is inherently C-centric -- everything outside the C niche does not,
indeed, fit flawlessly in the picture..
This is where the "if you want to write system software, do it in C"
model comes from.

5. If a killer use-case is needed, an X server might do -- these
need root privileges for a certain period.

What if i decide that i want to write one in Lisp?

> The more I hear, the more unconvinced I am by this use case.
> 
> If you don't care about the security issues created by (mis)using the lisp
> interpreter in this way, then like I suggested before, you can always
  ^^^^^^^^^^^ make that a compiler -- these days, probably, there are more
native-bytecode-generating lisp compilers than interpreters.

> write a tiny setuid-root wrapper program that turns off address space
> randomization and exec()s the lisp system executable, and leave the lisp
> system executable non-setuid and don't touch the code in the Linux kernel.
> That strikes me as a better solution: those who don't mind the security
> risks can take all the risks they want, without forcing others to take
> unwanted and unnecessary risks.

This might sound as a reasonable solution.

Although it places a certain burden, which has to be considered...

I should see what the SBCL people will say about that.

> It's not that I'm wedded to address space randomization of setuid
> programs, or that I think it would be a disaster if this patch were
> accepted.  Local privilege escalation attacks aren't the end of the world;
> in all honesty, they're pretty much irrelevant to many or most users.
> It's just that the arguments I'm hearing advanced in support of this
> change seem dubious, and the change does eliminate one of the defenses
> against a certain (narrow) class of attacks.
> 
> 
> [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 business can be.)  Setting the setuid-root
> bit on a large complex interpreter that wasn't designed to be setuid-root
> seems like a pretty dubious proposition to me.

Compiler, not interpreter, careful with the insults :-)

regards, Samium Gromoff

P.S. please cc me, as i am not subscribed to the list...

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] Undo some of the pseudo-security madness
  2007-01-21 22:09   ` Samium Gromoff
  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
  1 sibling, 2 replies; 38+ messages in thread
From: Arjan van de Ven @ 2007-01-22  0:35 UTC (permalink / raw)
  To: Samium Gromoff; +Cc: linux-kernel, David Wagner


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

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

-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] Undo some of the pseudo-security madness
  2007-01-21 22:09   ` Samium Gromoff
@ 2007-01-21 22:16     ` David Wagner
  2007-01-22  0:35     ` Arjan van de Ven
  1 sibling, 0 replies; 38+ messages in thread
From: David Wagner @ 2007-01-21 22:16 UTC (permalink / raw)
  To: linux-kernel

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

The obvious solution is: Don't make them setuid root.
Then this issue disappears.

If there is some strong reason why they need to be setuid root, then
you'll need to explain that reason and your requirements in more detail.
But, based on your explanation so far, I have serious doubts about
whether it is a good idea to make such core-dumps setuid root in the
first place.

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] Undo some of the pseudo-security madness
  2007-01-21  2:16 ` Arjan van de Ven
  2007-01-21 21:38   ` Samium Gromoff
@ 2007-01-21 22:09   ` Samium Gromoff
  2007-01-21 22:16     ` David Wagner
  2007-01-22  0:35     ` Arjan van de Ven
  1 sibling, 2 replies; 38+ messages in thread
From: Samium Gromoff @ 2007-01-21 22:09 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: Samium Gromoff, linux-kernel, David Wagner

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

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] Undo some of the pseudo-security madness
  2007-01-21  2:16 ` Arjan van de Ven
@ 2007-01-21 21:38   ` Samium Gromoff
  2007-01-21 22:09   ` Samium Gromoff
  1 sibling, 0 replies; 38+ messages in thread
From: Samium Gromoff @ 2007-01-21 21:38 UTC (permalink / raw)
  To: Arjan van de Ven; +Cc: Samium Gromoff, linux-kernel

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)
> > [1]. See the excellent, 'Hackers Hut' by Andries Brouwer, which describes
> > how AS randomisation can be got around by the means of linux-gate.so.1
> 
> got a URL to this? If this is exploiting the fact that the vdso is at a
> fixed spot... it's no longer the case since quite a while.

hmm, it seems to rely on that, yes:

http://www.win.tue.nl/~aeb/linux/hhh/hh-9.html#ss9.6
 
> -- 
> if you want to mail me at work (you don't), use arjan (at) linux.intel.com
> Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

regards, Samium Gromoff

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] Undo some of the pseudo-security madness
  2007-01-20 14:37 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
  2 siblings, 2 replies; 38+ messages in thread
From: Arjan van de Ven @ 2007-01-21  2:16 UTC (permalink / raw)
  To: Samium Gromoff; +Cc: linux-kernel

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)


> [1]. See the excellent, 'Hackers Hut' by Andries Brouwer, which describes
> how AS randomisation can be got around by the means of linux-gate.so.1

got a URL to this? If this is exploiting the fact that the vdso is at a
fixed spot... it's no longer the case since quite a while.


-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org


^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] Undo some of the pseudo-security madness
  2007-01-20 14:37 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
  2 siblings, 0 replies; 38+ messages in thread
From: David Wagner @ 2007-01-20 21:58 UTC (permalink / raw)
  To: linux-kernel

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.
>
>Secondly, there also are valid reasons to want those applications to be setuid
>root. Like poking hardware.

This has the unfortunate side-effect of making it easier for local
attackers to mount privilege escalation attacks against setuid binaries
-- even those setuid binaries that don't need unadulterated memory maps.

There's a cleaner solution to the problem case you mentioned.  Rather than
re-exec()ing itself, the application could be split into two executables:
the first is a tiny setuid-root wrapper which sets ADDR_NO_RANDOMIZE and
then executes the second program; the second is not setuid-anything and does
all the real work.  Such a decomposition is often better for security
for other reasons, too (such as the fact that the wrapper can drop all
unneeded privileges before exec()ing the second executable).

Why would you need an entire lisp system to be setuid root?  That sounds
like a really bad idea.  I fail to see why that is a relevant example.  
Perhaps the fact that such a lisp system breaks if you have security features
enabled should tell you something.

It may be possible to defeat address space randomization in some cases,
but that doesn't mean address space randomization is worthless.

It sounds like there is a tradeoff between security and backwards
compatibility.  I don't claim to know how to choose between those tradeoffs,
but I think one ought to at least be aware of the pros and cons on both
sides.

^ permalink raw reply	[flat|nested] 38+ messages in thread

* Re: [PATCH] Undo some of the pseudo-security madness
  2007-01-20 14:37 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
  2 siblings, 0 replies; 38+ messages in thread
From: Samium Gromoff @ 2007-01-20 16:12 UTC (permalink / raw)
  To: linux-kernel

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/personality.h		2007-01-20 17:31:01.000000000 +0300
+++ linux-sane/include/linux/personality.h	2007-01-20 17:32:50.000000000 +0300
@@ -40,7 +40,7 @@
  * Security-relevant compatibility flags that must be
  * cleared upon setuid or setgid exec:
  */
-#define PER_CLEAR_ON_SETID (READ_IMPLIES_EXEC|ADDR_NO_RANDOMIZE)
+#define PER_CLEAR_ON_SETID (READ_IMPLIES_EXEC)

Signed-off-by: Samium Gromoff <_deepfire@feelinfofgreen.ru>

^ permalink raw reply	[flat|nested] 38+ messages in thread

* [PATCH] Undo some of the pseudo-security madness
@ 2007-01-20 14:37 Samium Gromoff
  2007-01-20 16:12 ` Samium Gromoff
                   ` (2 more replies)
  0 siblings, 3 replies; 38+ messages in thread
From: Samium Gromoff @ 2007-01-20 14:37 UTC (permalink / raw)
  To: linux-kernel


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.

Secondly, there also are valid reasons to want those applications to be setuid
root. Like poking hardware.

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.

--- include/linux/personality.h	2007-01-20 17:31:01.000000000 +0300
+++ include/linux-sane/personality.h	2007-01-20 17:32:50.000000000 +0300
@@ -40,7 +40,7 @@
  * Security-relevant compatibility flags that must be
  * cleared upon setuid or setgid exec:
  */
-#define PER_CLEAR_ON_SETID (READ_IMPLIES_EXEC|ADDR_NO_RANDOMIZE)
+#define PER_CLEAR_ON_SETID (READ_IMPLIES_EXEC)
 
 /*
  * Personality types.

Signed-off-by: Samium Gromoff <_deepfire@feelinfofgreen.ru>

[1]. See the excellent, 'Hackers Hut' by Andries Brouwer, which describes
how AS randomisation can be got around by the means of linux-gate.so.1

^ permalink raw reply	[flat|nested] 38+ messages in thread

end of thread, other threads:[~2007-02-24 13:50 UTC | newest]

Thread overview: 38+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-01-21 23:23 [PATCH] Undo some of the pseudo-security madness 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-01-23 20:21           ` [PATCH 0/2] Mechanism to turn of ASR on a per-ELF binary basis Samium Gromoff
2007-01-23 20:28           ` [PATCH 1/2] Define the EF_AS_NO_RANDOM e_flag bit Samium Gromoff
2007-01-23 20:50             ` Jakub Jelinek
2007-01-23 21:06               ` Samium Gromoff
2007-01-23 21:16                 ` Jakub Jelinek
2007-01-23 21:54                   ` Samium Gromoff
2007-01-23 23:21                   ` Samium Gromoff
2007-01-24 17:08                     ` Pavel Machek
2007-01-29  1:18             ` Arjan van de Ven
2007-01-23 20:31           ` [PATCH 2/2] Make the EF_AS_NO_RANDOM e_flag bit disable PF_RANDOMIZE Samium Gromoff
2007-02-24  9:51           ` [PATCH] Undo some of the pseudo-security madness 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
  -- strict thread matches above, loose matches on Subject: below --
2007-01-22  0:54 Samium Gromoff
2007-01-20 14:37 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
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).