Re: Kernel-loadable Root Kits

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

_______________________________________________
[e-mail] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "[e-mail]"