Kernel-loadable Root Kits
David Pick
d.m.pick at qmul.ac.uk
Wed Sep 29 07:51:56 PDT 2004
>
> 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
More information about the freebsd-security
mailing list