你没有必要使用access_ok(...),因为上面列出的函数都自己检查这个。还有许多不一样的地方,但是你可以看看linux/module.h来获得一个详细的列表。
你没有必要使用access_ok(...),因为上面列出的函数都自己检查这个。还有许多不一样的地方,但是你可以看看linux/module.h来获得一个详细的列表。
我最后想提一件事情。我写了很多关于内核守护进程(kerneld)的东西。2.2版的内核不会再使用kerneld了。他使用另外一种方法来实现内核空间的request_module(...)函数-叫做kmod。kmod完全是运行在内核空间的(不再IPC到用户空间了)。对于LKM程序员来说,没有什么大的变化。你还是可以使用request_module(...)来加载模块。因此LKM传染者还是可以在2.2的内核中使用。
我很抱歉关于2.2内核只有这么少的东西。但是目前我正在写一个关于2.2内核安全的论文(特别是LKM的)。因此请注意新的THC发布的论文。我甚至计划工作在一些BSD系统上(FreeBSD,OpenBSD,例如)但是这会发几个月的时间。
第六部分 最后的话
6.1 LKM传奇以及如何使得一个系统即好用又安全
你大概会感到奇怪,既然LKM这么的不安全,那么为什么要使用他们呢。最初LKM是被设计使得用户更为方便的。Linux和Microsoft相对立,因此开发者们需要一个使得老的Unxi系统更为吸引人和容易的方法。他们实现了KDE和其他很好的东西。
比如说,kerneld就是被用来使得模块处理更为容易的。但是要记住,越为简单和自动化的系统就会有越多的安全问题。不可能同时使得一个系统既让用户感到很方便又有足够的安全性。模块就是一个很好的这样的例子。
Microsoft给了我们另外一个例子:考虑ActiveX,他(大概)是个好主意,用一个安全的设计来保证一切都是简单的。
因此,亲爱的Linux开发者们;请谨慎了,不要犯Microsoft的错误。不要创建一个好用,但是不安全的OS。把安全时刻记在心中!
这篇文章也很清楚的说明了任何系统的内核必须用最好的方法进行保护。不能让一个入侵者更改你系统中最为重要的部分。我把这个任务留给所有系统的设计者。