[21574] in bugtraq
Re: insmod/modprobe behaviour in regards to non-root-owned modules
daemon@ATHENA.MIT.EDU (Keith Owens)
Tue Jul 17 12:41:18 2001
From: Keith Owens <kaos@ocs.com.au>
To: Toby Corkindale <tjcorkin@sa.pracom.com.au>
Cc: bugtraq@securityfocus.com
In-reply-to: Your message of "Tue, 17 Jul 2001 16:05:56 +0930."
<Pine.LNX.4.33.0107171558290.26570-100000@localhost.localdomain>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 17 Jul 2001 16:51:32 +1000
Message-ID: <4389.995352692@kao2.melbourne.sgi.com>
On Tue, 17 Jul 2001 16:05:56 +0930 (CST),
Toby Corkindale <tjcorkin@sa.pracom.com.au> wrote:
>josh@pulltheplug.com posted to bugtraq earlier today with a case whereby
>modules.dep is set to mode 0666, and thus can be manipulated by a non-root
>user to cause a common module to load a user-owned evil module.
Fixed in 2.4.7-pre7, not released yet. It is a kernel bug, not
modutils.
>According to his post, Linux kernels from 2.4.3 onwards have a default empty
>umask, and thus on some distributions that do not explicity set the umask
>in time, a world-writeable modules.dep is created on bootup.
>
>This can be seen as a configuration error, perhaps, but I question whether
>modprobe should bypass the root-ownership test, which seems like a good
>idea.
>I guess there are cases where being able to specify an
>intentionally-non-root-owned module would be useful, but is that enough of a
>reason to bypass the security check?
You must explicitly bypass the security check by running insmod -r for
an individual module or depmod -r for all modules. Frankly I hate the
idea but some people share systems and deliberately set their
/lib/modules to 777 with modules.dep being 666. Foot, gun, shoot.
