public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Keith Owens <kaos@ocs.com.au>
To: "Adam J. Richter" <adam@freya.yggdrasil.com>
Cc: linux-kernel@vger.kernel.org, vendor-sec@lst.de
Subject: Re: Local root exploit with kmod and modutils > 2.1.121
Date: Wed, 15 Nov 2000 09:50:16 +1100	[thread overview]
Message-ID: <11108.974242216@ocs3.ocs-net> (raw)
In-Reply-To: Your message of "Tue, 14 Nov 2000 12:31:41 -0800." <200011142031.MAA07179@freya.yggdrasil.com>

On Tue, 14 Nov 2000 12:31:41 -0800, 
"Adam J. Richter" <adam@freya.yggdrasil.com> wrote:
>>The only secure fix I can see is to add SAFEMODE=1 to modprobe's
>>environment and change exec_modprobe.
>
>	SAFEMODE may mean other things to other programs, so that

MOD_SAFEMODE.

>	It would be much better to just add a command line option
>to modprobe that request_module() would cause it treat the following

Changing the command line is not an option.  Kernel 2.2 still runs with
modutils 2.1.121, changing the request_module command line would break
people using modutils 2.1.121 and force them to upgrade, AC would kill
me.  I needed a mechanism that would work with modutils 2.3 but have no
effect on modutils 2.1.121, remember that 2.1.121 does not have this
security exposure.  It also had to work on 2.2 kernels because many
people are using moditils 2.3 on 2.2 kernels.  SGI ship a 2.2 kernel
with devfs for their big machines, that needs modutils 2.3.

>	Another possible approach would be to create a separate
>/sbin/safe_modprobe.  modprobe already behaves differently
>based on whether argv[0] ends in "modprobe", "insmod", "depmod",
>or "rmmod".  So this would be in keeping with that convention.
>It would also be trivial to retrofit old systems.  Just have
>some system boot script do:
>
>		echo /sbin/safe_modprobe > /proc/sys/kernel/modprobe

I thought about that but it assumes that users will add that line to
their scripts - not guaranteed.  The fix needed a change that would
automatically detect that safe mode was required and not rely on manual
intervention.  Especially with 30+ Linux distributions out there.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

  reply	other threads:[~2000-11-14 23:20 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-11-14 20:31 Local root exploit with kmod and modutils > 2.1.121 Adam J. Richter
2000-11-14 22:50 ` Keith Owens [this message]
     [not found] <Pine.LNX.4.21.0011131915240.19775-100000@ferret.lmh.ox.ac.uk>
2000-11-13 23:11 ` Keith Owens
2000-11-16 16:04   ` Alan Cox
2000-11-16 17:05     ` kuznet
2000-11-16 17:19       ` Alan Cox
2000-11-16 17:32         ` kuznet
2000-11-16 18:24           ` Alan Cox
2000-11-16 18:56             ` kuznet
2000-11-16 20:24     ` Keith Owens
2000-11-16 21:45       ` Alan Cox
  -- strict thread matches above, loose matches on Subject: below --
2000-11-13 10:57 Keith Owens

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=11108.974242216@ocs3.ocs-net \
    --to=kaos@ocs.com.au \
    --cc=adam@freya.yggdrasil.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vendor-sec@lst.de \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox