tech-kern archive

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

Re: kernel module loading vs securelevel



On Mar 8,  9:44am, Thor Lancelot Simon wrote:
} On Sun, Oct 17, 2010 at 03:51:52AM +0900, Izumi Tsutsui wrote:
} > 
} > I'm just asking if "options INSECURE is mandaory to use autoloading,"
} > not module/autoloading is secure/silly/boo or not.
} 
} No.  As far as I can tell, there's a bug in the relevant kauth listener,
} at least in terms of the original intent of the author of the autoloading
} code; the system scope kauth listener should return DEFER, not DENY.

     module_listener_cb() was added to kern_module.c in revision 1.51
by elad.  The kauth_authorize_system() calls were added to
kern_module.c by ad, but the respective commit log messages doesn't say
anything about them, so the original intent of the author of the
autoloading code (ad) is unclear.

} However, I think it's a troublesome question whether this is really
} the right policy to apply.  Unless the directory from which modules are
} loaded is required to be immutable (flags schg) at boot time, this really
} does introduce a major security regression: now it is possible to override
} the whole security policy by placing a new kernel module in the existing
} directory, when the system is running at securelevel > 0.
} 
} I really only see two ways to keep the convenient behavior you and I both
} seem to want (autoload of modules when filesystems, syscalls, etc. are
} used) and the safe behavior I and others building (for example) embedded
} systems with tight security policies want: either we need to rely on
} the existing securelevel machinery and require that the directory from
} which autoload occurs is immutable at kernel boot time (elsewise disabling
} autoload), or we need to use something like veriexec, when we're still at
} securelevel < 0, to ensure that the modules placed there don't change in
} any way.

     I would have to agree.  Having modules loaded at securelevel > 0
when you can't be absolutely sure of what's in them, completely defeats
the purpose of running at securelevel > 0.

}-- End of excerpt from Thor Lancelot Simon


Home | Main Index | Thread Index | Old Index