Re: kernel module loading vs securelevel

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sat, Oct 16, 2010 at 12:03:52PM -0700, Paul Goyette wrote:
 > >> autoload/autounload does NOT perform any authorization checks -
 > >> please look at the code!  No checking of securelevel occurs, as far
 > >> as I can see.  For autoload, the module name must not contain a
 > >> '/', so if the module is being loaded from the file system it must
 > >> be loaded from the "blessed" /stand/${ARCH}/${VERSION}/modules
 > >> directory.  Including the INSECURE option will have no effect on
 > >> autoloading of modules.
 > >
 > >If this is true it makes securelevel useless; all you need to do is
 > >put a hostile module in the right place and cause it to be autoloaded.
 > >(Remember the point of securelevel is that even root can't lower it.)
 > 
 > John Nemeth has already pointed out that my reading of the code was
 > flawed.  Module autoloading _does_ call kauth for authorization.
 > The kauth listener provided by the module subsystem returns ALLOW
 > for all autoload calls, but this gets overridden by another kauth
 > listener, so autoload still gets denied.

Good that it's not true then :-)

 > >It should be sufficient, I think, to check at boot time that any
 > >module that can be autoloaded is marked immutable.
 > 
 > And also make the "blessed" directory itself immutable?  :)

As I recall the semantics of immutable are such that this isn't
necessary to protect modules that are present at boot time (that is,
they can't be unlinked/renamed/etc.), and if there are autoloadable
modules whose names aren't present at boot time, they'll fail the
check.

-- 
David A. Holland
dholland%netbsd.org@localhost