linux 的安全特性是不受信任的代码是在 seccomp 下运行的解释语言，系统调用由类似 seccomp 的 utrace 策略调解，在限制性 linux 容器内，并在限制性 AppArmor 配置文件下。

... 傻瓜。以一种好的方式。

它可以绕过 linux 访问策略直接对主机 windows 操作系统进行系统调用吗？

嗯，这个问题的答案取决于你如何可视化和其他一些因素——这真的需要一个“虚拟化如何工作”的解释来涵盖它。

假设 Intel-VT，我在这里介绍了一些深度（加上链接）虚拟化。作为一个非常简短的总结，您的主机执行通常的操作系统操作 - 页表，调用门描述符。然后为了运行虚拟机，主机设置另一个表来描述虚拟机，包括虚拟机的内存映射，然后运行一条VMXON指令 - 然后创建虚拟机。

从虚拟机的角度来看，它所呈现的内存是它可用的整个系统内存——与普通应用程序的虚拟内存相同。在正常的虚拟化场景下，您不会向来宾提供主机运行的相同内存 - 您给它自己的空间，这意味着它不能直接访问您现有的任何设置。

但是，如果您可以将主机内存映射到 guest，要直接进行主机系统调用，您需要能够引发向主机注册的中断。这是 NT 文档的一个相当好的内部结构——它与 Windows 有很大的不同，要真正实现它可能需要修改你的内核，我有理由相信如果你按原样暴露内存，你要么破坏 Windows，否则你会破坏 Linux。当然，这是假设您将主机内存映射到来宾虚拟机...我可能不太清楚，所以要确切地说出问题所在 - linux 已注册int 80（或正在使用sysenter）；Windows正在注册int 2e或sysenter（另一篇好文章- 与前一个作者相同））。如果其中一个空闲，他们肯定可以注册不同的软件中断处理程序……但是sysenter如果不进行修改，共享将是不可能的-这只是内存位置的问题。当我们谈论调用约定时，事情变得更加棘手......

不过，我们还没有完全走出困境。虽然如果没有一些严肃的工程来修改所涉及的平台，显然您不能直接轻松地调用主机的系统调用，但有时需要某种方式与主机通信。有 - 一条VMCall指令（在来宾中）导致VMExit主机与信息交换，以便主机可以提供请求 - 如果这里有任何漏洞，您可能会间接调用系统调用或调用。每当您和主机需要共享 CPU 和内存以外的东西时，就会发生这种情况。英特尔 VT-d致力于在硬件中根据需要提供 DMA，从而避免了某些类别的设备对 VMCall 的需求。

如果您进行软件虚拟化，情况会略有不同。要提供相同的功能，您必须编写一个 CPU 模拟器 - 但是，这是一个主机运行进程，因此如果您可以注入代码并执行它，您可以在模拟器拥有的任何权限的上下文中调用系统调用。这与 JVM 中的错误（非常松散，有点免责声明：比喻地说）相当 - 可以将 shellcode 注入 VM 的格式错误的 java 字节码会做一些令人讨厌的事情，无论 JVM 提供的安全性如何.

我应该在这里添加显而易见的 - 我正在谈论工程和虚拟机问题。如果您设置了一个dodgy.exe由恶意代码提供的 samba 共享并双击，那么游戏就结束了。听起来这对您来说是一个明显的陈述——但以防万一其他人认为虚拟机解决了他们所有的问题……不完全是。

各种参考：

• Codeproject 的 VM 指令汇编参考。
• bluepill 真的无法检测到吗- 重要的是要了解将主机映射到自身（主机内存空间的映射部分的子集到（不同操作系统）来宾的子集）有多难......
• 赛门铁克对虚拟机模拟器的攻击。讨论了我讨论过的一些事情，有点被蓝色药丸类型的东西分心，但仍然是一本非常好的读物。

tl;博士

在基于硬件的虚拟化中，直接从客户机调用属于主机的系统调用是非常困难的（几乎到了重建部分操作系统的地步）；当他们使用不同的操作系统时更是如此。间接利用是可能的，但随后需要管理程序代码或其使用中的漏洞。

简短的回答是“否”（除非管理程序代码中存在漏洞/错误）。来宾代码不能调用主机操作系统中的系统调用，除非通过中断虚拟机。这就是虚拟机的工作方式。在虚拟机内运行的客户代码无法直接调用主机操作系统系统调用，除非利用管理程序中的一些漏洞来突破虚拟机。现代管理程序旨在防止这种情况发生，虽然管理程序中的错误/漏洞并非不可能并且已经发生，但它们很少见。

我实际上对这个问题有点困惑，所以我希望我已经回答了你心中的问题。一旦我们删除了干扰因素和无关紧要的细节，我理解您是在问“恶意来宾代码可以调用主机操作系统并要求它执行系统调用吗？” 如果这就是您要问的，那么答案是“否”，因为虚拟机只是没有为来宾代码提供任何方式来调用主机操作系统系统调用。如果这不是您想知道的，请详细说明。