将流程置于对环境危害最小的沙箱中

时间:2020-03-06 14:44:50  来源:igfitidea点击:

我正在寻找产生这样一个过程的概念:

  • 它只能访问某些库/ API
  • 它不能访问文件系统或者仅特定部分
  • 如果其中运行了恶意代码,则危害最小

这个概念被称为沙盒或者监狱。

必须在每个主要操作系统(Windows,MacOSX和Linux)上执行此操作,并且问题是概念性的(例如要执行的操作,使用的API和观察的内容),而不是特定于语言。

回答要求

我真的很想接受答案,并为此给我们20分。我无法接受自己的答案,而且我还没有答案。因此,如果我们确实希望答案被接受,请注意:

  • 答案必须是具体且完整的
  • 具体来说,我的意思是,它不只是指向互联网上某些资源的指针。它必须至少总结资源对主题的看法。
  • 它可能包含示例代码,也可能不包含,但是如果包含示例代码,请用C编写
  • 即使那里的2/3是完美的,我也不能接受2/3的答案。

这个问题的常见问题

  • 这是功课吗?不。
  • 你为什么像作业一样问这个问题?如果我们提出一个特定的问题并且想要获得一个特定的答案,并且我们知道该答案的外观,即使我们不知道答案,这就是我们所遇到的问题的风格。
  • 如果我们知道它的外观,为什么要问? 1)因为我不知道所有答案2)因为在互联网上,没有一个地方将一个问题的所有细节都集中在一个地方。另请阅读stackoverflow常见问题解答
  • 为什么问题的主要部分如何回答这个问题?因为没有人阅读常见问题解答。

解决方案

FreeBSD具有监狱的特定概念,而Solaris具有容器。取决于我们要寻找的内容,这些可能会有所帮助。

chroot jails可以帮助限制应用程序可以执行的操作(尽管任何具有root特权的应用程序都可以越狱),并且它们在包括OS X在内的大多数UNIXen上都可用。

至于Windows,我不确定。我敢肯定,如果有一种简便的方法可以将Windows应用程序沙箱化,那么现在大多数应用程序都将更加安全。

对于Windows,Google Chrome中有一个沙箱。我们可能需要调查。它使用类似BSD的自由许可证。

对于Linux,最好使用旧的chroot或者更复杂的http://plash.beasts.org/wiki/。

自Leopard以来的OS X具有一些类似于SELinux的保护。

对于Linux,有AppArmor。不幸的是,该项目有些中断。
另一个沙盒替代方案是使用虚拟化的VServer。

在Windows(2000及更高版本)上,我们可以使用Job对象来限制进程。

Mac OS X具有一个代号为Seatbelt的沙盒工具。在sandbox(7),sandbox_init(3)和相关手册页中记录了针对它的公共API。公用API有所限制,但是该工具本身非常强大。尽管公共API仅允许我们从一些预定义的沙箱中进行选择(例如,禁止使用所有基于套接字的网络),但我们也可以使用功能更强大的基础实现,该实现可让我们确切地指定通过Scheme-可用的操作系统资源。喜欢语言。例如,这是用于portmap的沙箱的摘录:

(allow process-exec (regex #"^/usr/sbin/portmap$"))
(allow file-read-data file-read-metadata (regex
    #"^/etc"
    #"^/usr/lib/.*\.dylib$"
    #"^/var"
    #"^/private/var/db/dyld/"
    #"^/dev/urandom$"))
(allow file-write-data (regex
    #"^/dev/dtracehelper$"))

我们可以在/ usr / share / sandbox中看到系统使用的许多沙箱。使用sandbox-exec(1)命令可以很容易地尝试使用沙箱。

对于Windows,我们可能需要看一下在Black Hat USA 2007上发表的David LeBlancs实用沙箱讨论。Windows本身没有内置的沙箱技术,因此所描述的技术利用了Windows 2000引入的称为SAFER的不完整机制。通过使用受限令牌,可以创建对操作系统资源具有受限访问权限的进程。

对于Linux,我们可以研究复杂的SELinux机制:
SELinux主页,
一个HOWTO。例如,它被Red Hat用来强化其某些产品中的某些系统服务。

站点codepad.prg上有一个很好的"关于"页面,介绍了它们如何安全地执行任何代码段。

Code execution is handled by a supervisor based on geordi. The strategy is to run everything under ptrace, with many system calls disallowed or ignored. Compilers and final executables are both executed in a chroot jail, with strict resource limits. The supervisor is written in Haskell.
  
  When your app is remote code execution, you have to expect security problems. Rather than rely on just the chroot and ptrace supervisor, I've taken some additional precautions:
  
  
  The supervisor processes run on virtual machines, which are firewalled such that they are incapable of making outgoing connections.
  The machines that run the virtual machines are also heavily firewalled, and restored from their source images periodically.

我不是该主题的专家,但是我认为linux的标准答案是定义具有正确功能的SeLinux策略。

如果我们真的想要一种适用于所有这些平台的技术,而不是针对每个平台的单独解决方案,那么我认为我们唯一的答案就是为每个测试环境设置一个虚拟机。我们可以随时还原回快照。

使用虚拟化的另一个主要优点是,我们可以将所有测试环境及其来宾操作系统都放在同一盒中。