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. 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. Someone is going to ask me "why do you want modules at all on a system with a tight security policy?" The answer, unfortunately, is licensing, and in particular CDDL code. You can load it into your kernel without pulling the entire kernel sources under CDDL but you cannot link it into your kernel at compile time. :-/ Thor
