Security Issues

Security is an increasingly important concern in modern times. We will discuss security-related issues as they come up throughout the book. There are a few general concepts, however, that are worth mentioning now. 在现代，安全是一个越来越重要的问题。 我们将讨论整本书中出现的与安全相关的问题。 但是，现在有一些一般概念值得一提。

Any security check in the system is enforced by kernel code. If the kernel has security holes, then the system as a whole has holes. In the official kernel distribution, only an authorized user can load modules; the system call init_module checks if the invoking process is authorized to load a module into the kernel. Thus, when running an official kernel, only the superuser,[1] or an intruder who has succeeded in becoming privileged, can exploit the power of privileged code. 系统中的任何安全检查都由内核代码强制执行。 如果内核有安全漏洞，那么整个系统就有漏洞。 在官方内核发行版中，只有授权用户才能加载模块； 系统调用 init_module 检查调用进程是否被授权将模块加载到内核中。 因此，在运行官方内核时，只有超级用户 [1] 或成功获得特权的入侵者才能利用特权代码的力量。

When possible, driver writers should avoid encoding security policy in their code. Security is a policy issue that is often best handled at higher levels within the kernel, under the control of the system administrator. There are always exceptions, however. As a device driver writer, you should be aware of situations in which some types of device access could adversely affect the system as a whole and should provide adequate controls. For example, device operations that affect global resources (such as setting an interrupt line), which could damage the hardware (loading firmware, for example), or that could affect other users (such as setting a default block size on a tape drive), are usually only available to sufficiently privileged users, and this check must be made in the driver itself. 如果可能，驱动程序编写者应避免在其代码中编码安全策略。 安全性是一个策略问题，通常最好在系统管理员的控制下在内核中的更高级别处理。 然而，总是有例外。 作为设备驱动程序编写者，您应该了解某些类型的设备访问可能会对整个系统产生不利影响的情况，并且应该提供足够的控制。 例如，影响全局资源（例如设置中断线）、可能损坏硬件（例如加载固件）或可能影响其他用户（例如在磁带驱动器上设置默认块大小）的设备操作 , 通常只对有足够特权的用户可用，并且必须在驱动程序本身中进行此检查。

Driver writers must also be careful, of course, to avoid introducing security bugs. The C programming language makes it easy to make several types of errors. Many current security problems are created, for example, by buffer overrun errors, in which the programmer forgets to check how much data is written to a buffer, and data ends up written beyond the end of the buffer, thus overwriting unrelated data. Such errors can compromise the entire system and must be avoided. Fortunately, avoiding these errors is usually relatively easy in the device driver context, in which the interface to the user is narrowly defined and highly controlled. 当然，驱动程序编写者也必须小心，以避免引入安全漏洞。 C 编程语言很容易犯多种类型的错误。 许多当前的安全问题是由缓冲区溢出错误造成的，其中程序员忘记检查有多少数据写入缓冲区，数据最终写入缓冲区末尾，从而覆盖不相关的数据。 此类错误会危及整个系统，必须避免。 幸运的是，在设备驱动程序上下文中避免这些错误通常相对容易，其中与用户的接口被严格定义和高度控制。

Some other general security ideas are worth keeping in mind. Any input received from user processes should be treated with great suspicion; never trust it unless you can verify it. Be careful with uninitialized memory; any memory obtained from the kernel should be zeroed or otherwise initialized before being made available to a user process or device. Otherwise, information leakage (disclosure of data, passwords, etc.) could result. If your device interprets data sent to it, be sure the user cannot send anything that could compromise the system. Finally, think about the possible effect of device operations; if there are specific operations (e.g., reloading the firmware on an adapter board or formatting a disk) that could affect the system, those operations should almost certainly be restricted to privileged users. 其他一些一般的安全理念也值得牢记。 从用户进程收到的任何输入都应该受到高度怀疑； 除非您可以验证它，否则永远不要相信它。 小心未初始化的内存； 从内核获得的任何内存在提供给用户进程或设备之前都应该清零或以其他方式初始化。 否则，可能导致信息泄露（数据、密码等泄露）。 如果您的设备解释发送给它的数据，请确保用户不能发送任何可能危及系统的内容。 最后，想想设备操作可能产生的影响； 如果有可能影响系统的特定操作（例如，在适配器板上重新加载固件或格式化磁盘），则几乎可以肯定这些操作应仅限于特权用户。

Be careful, also, when receiving software from third parties, especially when the kernel is concerned: because everybody has access to the source code, everybody can break and recompile things. Although you can usually trust precompiled kernels found in your distribution, you should avoid running kernels compiled by an untrusted friend—if you wouldn't run a precompiled binary as root, then you'd better not run a precompiled kernel. For example, a maliciously modified kernel could allow anyone to load a module, thus opening an unexpected back door via init_module. 当从第三方接收软件时也要小心，尤其是涉及内核时：因为每个人都可以访问源代码，所以每个人都可以破坏和重新编译东西。 尽管您通常可以信任在您的发行版中找到的预编译内核，但您应该避免运行由不受信任的朋友编译的内核——如果您不以 root 身份运行预编译的二进制文件，那么您最好不要运行预编译的内核。 例如，恶意修改的内核可能允许任何人加载模块，从而通过 init_module 打开意外的后门。

Note that the Linux kernel can be compiled to have no module support whatsoever, thus closing any module-related security holes. In this case, of course, all needed drivers must be built directly into the kernel itself. It is also possible, with 2.2 and later kernels, to disable the loading of kernel modules after system boot via the capability mechanism. 请注意，Linux 内核可以编译为不支持任何模块，从而关闭任何与模块相关的安全漏洞。 当然，在这种情况下，所有需要的驱动程序都必须直接内置到内核本身中。 对于 2.2 及更高版本的内核，也可以通过功能机制在系统引导后禁用内核模块的加载。