出于安全原因，最好在执行之前检查代码的完整性，避免软件被篡改由攻击者发起。所以，我的问题是
如何在Linux下对可执行代码进行签名并仅运行受信任的软件？
我读过范杜姆的作品et al., Linux 签名可执行文件的设计和实现，以及 IBM 的TLC http://domino.research.ibm.com/comm/research_projects.nsf/pages/gsal.TCG.html（可信 Linux 客户端）由 Safford 和 Zohar 编写。 TLC 使用 TPM 控制器，这很好，但该论文是 2005 年的，我无法找到当前的替代方案。
您知道其他选择吗？
UPDATE：其他操作系统呢？开放Solaris？ BSD家族？
我意识到这是一个古老的问题，但我现在才发现它。
不久前，我为 Linux 内核（大约版本 2.4.3）编写了签名可执行文件支持，并准备好了用于签名可执行文件的整个工具链，在以下位置检查签名execve(2)时间，缓存签名验证信息（在打开文件进行写入或以其他方式修改时清除验证），将签名嵌入到任意 ELF 程序中等。它确实在每个程序的第一次执行时引入了一些性能损失（因为内核必须加载到entire文件，而不仅仅是按需分页所需的页面），但一旦系统处于稳定状态，它就会运行良好。
但我们决定停止追求它，因为它面临着几个太大的问题，无法证明其复杂性：
-
我们还没有建立对签名库。签名库还需要修改ld.so装载机和dlopen(3)机制。这并非不可能，但确实使接口变得复杂：我们应该让加载程序要求内核验证签名还是应该完全在用户空间中完成计算？如何防范strace(2)d 进程如果这部分验证是在用户空间中完成的？我们会被迫禁止吗strace(2)完全依靠这样的系统吗？
我们会做什么提供自己的加载程序的程序 http://www.catonmat.net/blog/ldd-arbitrary-code-execution/?
许多程序都是用不能编译为 ELF 对象的语言编写的。我们需要提供特定于语言的的修改bash, perl, python, java, awk, sed等等，以便每个口译员能够also验证签名。由于大多数这些程序都是自由格式的纯文本，因此它们缺乏将数字签名嵌入到 ELF 目标文件中如此简单的结构。签名将存储在哪里？在脚本中？在扩展属性中？在外部签名数据库中？
很多口译员都是张大关于他们允许的事情；bash(1)可以与远程系统通信完全靠自己 using echo and /dev/tcp，并且很容易被诱骗执行攻击者需要做的任何事情。无论是否签名，一旦它们受到黑客的控制，您就无法信任它们。
签名可执行文件支持的主要动机来自 Rootkit 取代了系统提供的/bin/ps, /bin/ps, /bin/kill， 等等。是的，签署可执行文件还有其他有用的理由。然而，随着时间的推移，rootkit 变得更加令人印象深刻，许多人依赖于kernel黑客向管理员隐藏他们的活动。一旦内核被破解，整个游戏就结束了。由于 Rootkit 的复杂性，我们希望阻止其使用的工具在黑客社区中逐渐失宠。
内核的模块加载接口是完全开放的。一旦一个进程有root特权，很容易注入内核模块而无需任何检查。我们还可以为内核模块编写另一个验证器，但围绕模块的内核基础设施非常原始。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
