LKML Archive on
help / color / mirror / Atom feed
From: (David Wagner)
Subject: Re: [PATCH] Undo some of the pseudo-security madness
Date: Sat, 20 Jan 2007 21:58:08 +0000 (UTC)	[thread overview]
Message-ID: <eou39g$a8r$> (raw)
In-Reply-To: <>

Samium Gromoff  wrote:
>This patch removes the dropping of ADDR_NO_RANDOMIZE upon execution of setuid
>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
>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

  parent reply	other threads:[~2007-01-20 23:09 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-20 14:37 Samium Gromoff
2007-01-20 16:12 ` Samium Gromoff
2007-01-20 21:58 ` David Wagner [this message]
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
2007-01-21 23:23 Samium Gromoff
2007-01-21 23:34 ` David Wagner
2007-01-22  0:36   ` Kyle Moffett
2007-01-22  1:53     ` Samium Gromoff
2007-02-24  9:40       ` Florian Weimer
2007-02-24 13:33         ` Samium Gromoff
2007-02-24 13:49           ` Florian Weimer
2007-01-22 15:20 ` Valdis.Kletnieks
2007-01-22 17:39   ` Samium Gromoff
2007-01-23  8:48     ` Pavel Machek
2007-01-23 14:03       ` Samium Gromoff
2007-01-23 15:41         ` Alan
2007-02-24  9:51           ` Florian Weimer
2007-02-24 13:36             ` Samium Gromoff
2007-01-31  9:59         ` Arjan van de Ven
2007-02-01  8:05           ` Florian Weimer
2007-01-22  0:54 Samium Gromoff

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='eou39g$a8r$' \ \ \ \
    --subject='Re: [PATCH] Undo some of the pseudo-security madness' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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