tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: kernel module loading vs securelevel

On Sun, 17 Oct 2010, Masao Uebayashi wrote:

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

} 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.

Ah, I see.  That definitely explains it.

| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at    |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at |
| Kernel Developer |                          | pgoyette at  |

Home | Main Index | Thread Index | Old Index