> > Thanks for the module, I think its a good idea to commit it to FreeBSD > for a few reasons: > > 1) Some folks just prefer more static kernels. > > 2) Securelevel is a great thing, but can be a pain to do upgrades around > remotely. [A lot of folks use FreeBSD simply because its a breeze to run > remotely]. > > 3) Until someone writes code to add modules to a kernel via /dev/mem and > releases it to the script kiddie world, the bar has been effectively > raised for 99% of the miscreants out there. > > 4) Marketing-wise, it will make folks who don't understand the issues > very deeply more comfortable. And as in #3, that is probably a 99% > accurate feeling. > > 5) For those of us using automatic updating systems, having modules and > kernels out of sync is bad potentially, so NO_KLD helps keep that from > being an issue. 6) securelevel *is* a great thing but sysadmins are tied to the hierarchy of levels chosen by the project, and one size does *not* fit all. As a more general mechanism I would suggest that there is a kernel-build option for *each* facility that can be locked by securelevel, which geves the level at which that facility becomes locked. Then, someone who builds a kernel can choose the hierarchy for themselves. Of course, the defaults for the options would give the existing behaviour. The net result would be a much more flexible mechanism that would allow someone to choose just which facilities they want available or not at run-time. Just as an example I would like to allow firewall rule-sets to be changed but disallow module loading (after bootup). Think of it as a kernel-build-time capability system. -- David Pick _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"