TH.*_*TH. 35 linux security linux-kernel trusted-computing
出于安全原因,希望在执行之前检查代码的完整性,避免攻击者篡改软件.所以,我的问题是
如何在Linux下签署可执行代码并仅运行可信软件？
我读过van Doom 等人的着作.,设计和实现Linux的签名可执行文件,以及Safford&Zohar 的IBM TLC(可信Linux客户端).TLC使用TPM控制器,这很好,但该文件来自2005年,我无法找到当前的替代品.
你知道其他选择吗？
更新:关于其他操作系统？OpenSolaris的？BSD家庭？
sar*_*old 58
我意识到这是一个古老的问题,但我现在才发现它.
我前段时间为Linux内核(版本2.4.3)编写了签名的可执行支持,并为整个签署可执行文件的工具链,检查签名execve(2),缓存签名验证信息(清除文件时的验证)开放写入或以其他方式修改),将签名嵌入任意ELF程序等.它确实在每个程序的第一次执行时引入了一些性能损失(因为内核必须加载整个文件,而不仅仅是需求页面需要的页面)但一旦系统处于稳定状态,它运作良好.
但是我们决定停止追求它,因为它面临着一些太大而无法证明复杂性的问题:
我们还没有建立对签名库的支持.签名库还需要修改ld.so加载器和dlopen(3)机制.这并非不可能,但确实使接口复杂化:我们是否应该让加载程序要求内核验证签名,还是应该完全在用户空间中完成计算？strace(2)如果验证的这部分在用户空间中完成,那么如何防止d进程？我们会被迫strace(2)完全禁止这样的系统吗？
对于提供自己的装载机的程序,我们会怎么做？
许多程序都是用不编译为ELF对象的语言编写的.我们需要提供特定于语言的修改bash,perl,python,java,awk,sed,等等,对于每个解释的要能也验证签名.由于大多数这些程序都是自由格式的纯文本,因此缺少将数字签名嵌入ELF目标文件的结构.签名将存储在哪里？在脚本中？在扩展属性？在签名的外部数据库中？
许多口译员对他们允许的内容持开放态度; bash(1)可以使用和完全独立地与远程系统通信,并且可以很容易地欺骗执行攻击者需要做的任何事情.签名与否,一旦他们受到黑客的控制,你就无法信任他们.echo/dev/tcp
对于签名的可执行文件支持的主要动力来自于rootkit的更换系统提供的/bin/ps,/bin/ps,/bin/kill,等等.是的,签署可执行文件还有其他有用的理由.但是,随着时间的推移,rootkit会更加令人印象深刻,许多人依赖内核攻击来隐藏管理员的活动.一旦内核被黑了,整个游戏就结束了.由于rootkit的复杂性,我们希望防止使用的工具在黑客社区中不再受欢迎.
内核的模块加载接口是开放的.一旦进程具有root权限,就可以很容易地注入内核模块而无需进行任何检查.我们本可以为内核模块编写另一个验证程序,但内核的模块基础结构非常原始.
Dan*_*ing 11
GNU/Linux/FOSS模型实际上鼓励篡改 - 一种.用户和发行商必须可以自由地修改(篡改)软件以满足他们的需求.即使只是重新编译软件(不改变任何源代码)进行自定义也是经常做的事情,但会破坏二进制代码签名.因此,二进制代码签名模型并不特别适合GNU/Linux/FOSS.
相反,这种软件更多地依赖于生成源包的签名和/或安全哈希.结合可靠且值得信赖的包分发模型,这可以像二进制代码签名一样安全(如果不是更多,相对于源代码的透明性).
| 归档时间： |
|
| 查看次数： |
26483 次 |
| 最近记录： |