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