Re: kernel module loading vs securelevel

[Thor Lancelot Simon <tls%panix.com@localhost>]

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