Re: I: kmod vs module-init-tools: modprobe security regression

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

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


-- 
ldv

Attachment: pgpbp7tlU9AAW.pgp
Description: PGP signature


[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Big List of Linux Books]

  Powered by Linux