Re: kernel module loading vs securelevel

[Masao Uebayashi <uebayasi%tombi.co.jp@localhost>]

On Sat, Oct 16, 2010 at 08:57:04AM -0700, John Nemeth wrote:
> On Jan 31,  5:14pm, Paul Goyette wrote:
> } On Sat, 16 Oct 2010, Izumi Tsutsui wrote:
> } 
> } >>> Hmm, what do you think about this feature?
> } >>> Only available in INSECURE environment?
> } >
> } >> We trust modules at the time when they're installed into the trusted
> } >> place, same as kernel itself.  I think prohibiting module load  at
> } >> run-time is rather pointless.
> } >
> } > Well I think the point is whether we should require INSECURE or not
> } > to use module autoload/autounload after multiuser.
> } >
> } > If we should I'll enable options INSECURE by default on ports
> } > that require options MODULAR (to save kernel file size).
> } 
> } autoload/autounload does NOT perform any authorization checks - please 
> } look at the code!  No checking of securelevel occurs, as far as I can 
> 
>      I just did and autoload most certainly does do authorization
> checks.
> 
> } 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.
> } 
> } Manual loading and unloading of modules does involve calls to 
> } kauth_authorize_system() which will check securelevel.
> 
>      sys/kern/kern_module.c:module_autoload() makes almost the exact
> same call to kauth_authorize_system as does module_load().  The
> difference is that the second last parm is (void *)(uintptr_t)1.  What
> difference this makes is going to be buried in the bowels of kauth, and
> I'm not going to dig through that at this moment.

I read it as:

 a) module_listener_cb() checks the 2nd arg, if autoload, judge the auth
    as "allow"

 b) secmodel_securelevel_system_cb() denies the auth if (securelevel >
    0) regardless of autoload

Kauth disallows the auth, because >0 listner(s) denied.

Masao

> 
> }-- End of excerpt from Paul Goyette

-- 
Masao Uebayashi / Tombi Inc. / Tel: +81-90-9141-4635