On Tue, Aug 14, 2012 at 7:25 PM, Dmitry V. Levin <ldv@xxxxxxxxxxxx> wrote: > On Tue, Aug 14, 2012 at 06:27:36PM -0300, Lucas De Marchi wrote: >> On Tue, Aug 14, 2012 at 5:56 PM, Dmitry V. Levin wrote: >> > >> > The new edition of modprobe provided by kmod, unlike the old one from >> > module-init-tools, doesn't honour blacklist by default when processing >> > aliases. >> > >> > Back in 2005, when blacklist support in modprobe was first added for >> > module-init-tools, it was implemented that way deliberately: >> > http://lkml.org/lkml/2005/5/11/74 >> > >> > Since 2005 the feature became quite popular. In particular, it is used >> > as a method to "unalias" all kinds of aliases for the given module. >> > I'm aware of many default configurations where such constructs as >> > "alias net-pf-3 off" were rewritten as "blacklist ax25". >> > Unfortunately, these configurations not just break with migration from >> > module-init-tools to kmod, but also introduce a vulnerability: an >> > unprivileged user can use socket(2) syscall to make the kernel load >> > various modules implementing rare network protocols which used to be >> > blacklisted. Some of these modules had various security bugs in the past >> > (like CVE-2009-2909 in ax25 mentioned above), and are likely to be less >> > audited than more widespread network protocols, so unguarded access to >> > these modules poses a security risk. >> > >> > What I'd like to know is what was the rationale for the change in modprobe >> >> What's the change? > > As I said, modprobe from module-init-tools honours blacklist by default > when processing aliases, but modprobe from kmod doesn't. the key here is "when processing aliases", which was not so clear for me. > > For example, "blacklist ax25" makes "modprobe net-pf-3" a noop in case of > module-init-tools, while the modprobe from kmod loads ax25 despite of > blacklist. Assuming that kmod aims to replace module-init-tools, this > qualifies as a change in behaviour. So the answer is: it was not designed to be a change in behavior, but it's rather a bug. I'll take a look on it. > >> > behaviour and how do you propose to deal with the security regression it >> > introduced? >> >> there shouldn't be a change in behaviour. Could you provide an example >> the results are different and if possible add it to >> testsuite/test-blacklist.c? > > Is testsuite/test-blacklist.c an appropriate place for modprobe tests? > It rather looks as a place for libkmod tests. yes, or testsuite/test-modprobe.c, which already has other calls to modprobe. Lucas De Marchi -- To unsubscribe from this list: send the line "unsubscribe linux-modules" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
