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/
next prev parent 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