LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: daw@cs.berkeley.edu (David Wagner)
To: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Undo some of the pseudo-security madness
Date: Sun, 21 Jan 2007 23:34:56 +0000 (UTC)	[thread overview]
Message-ID: <ep0tb0$f6e$1@taverner.cs.berkeley.edu> (raw)
In-Reply-To: <87r6toufpp.wl@betelheise.deep.net>

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.

  reply	other threads:[~2007-01-21 23:58 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-21 23:23 Samium Gromoff
2007-01-21 23:34 ` David Wagner [this message]
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

Reply instructions:

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

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

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to='ep0tb0$f6e$1@taverner.cs.berkeley.edu' \
    --to=daw@cs.berkeley.edu \
    --cc=daw-usenet@taverner.cs.berkeley.edu \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: [PATCH] Undo some of the pseudo-security madness' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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

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