Re: kernel module loading vs securelevel

[Andrew Doran <ad%NetBSD.org@localhost>]

Hi Thor.

On Sat, Oct 16, 2010 at 03:08:45PM -0400, 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.
> 
> 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 may be missing your point but there are other ways of sabotaging
the securelvel mechanism without kernel modules available.  It doesn't
seem like a new problem to me.  A more obvious way to be mischievous
for sure but not new.
 
> 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.  :-/