内存安全和保障 - 沙箱任意程序？
在某些语言（Java、没有不安全代码的 C# 等）中，（应该）不可能损坏内存 - 无需手动内存管理等。这允许它们限制资源（访问文件、访问网络、最大内存）用法，...）很容易地应用到应用程序 - 例如Java小程序（Java web start）。有时称为沙箱。
我的问题是：本机程序是否可能（例如，用 C、C++ 等内存不安全语言编写；但没有源代码）？我指的不是简单的可绕过沙箱或防病毒软件。
我考虑两种可能性：
- 以不同的操作系统用户身份运行应用程序，为此用户设置限制。缺点 - 许多用户，对于每个参数组合，访问权限如何？
- （以某种方式）限制可以调用的（操作系统API）函数 我不知道是否有任何可能性允许（至少在理论上）完全保护，而没有绕过的可能性。
编辑：我对理论更感兴趣 - 我不关心例如某些操作系统具有一些未记录的功能，或者如何在给定操作系统上沙箱任何应用程序。例如，我想要沙箱应用程序并只允许两个功能：从控制台获取字符，将字符放入控制台。怎么可能做到牢不可破，没有绕过的可能？
提到的答案：
- Google Native Client，使用 x86 的子集 - 正在开发中，以及（可能？）PNaCl - 便携式本机客户端
- 完整虚拟机 - 显然矫枉过正，想象数十个程序......
换句话说，可以本机（不安全的内存访问）代码可以在受限环境中使用，例如在网络浏览器中，具有 100%（至少理论上）的安全性吗？
Edit2：Google Native Client正是我想要的 - 任何语言，安全或不安全，以本机速度运行，沙箱，甚至在网络浏览器中。每个人都可以使用您想要的任何语言，无论是在网络上还是在桌面上。
In some languages (Java, C# without unsafe code, ...) it is (should be) impossible to corrupt memory - no manual memory management, etc. This allows them to restrict resources (access to files, access to net, maximum memory usage, ...) to applications quite easily - e.g. Java applets (Java web start). It's sometimes called sandboxing.
My question is: is it possible with native programs (e.g. written in memory-unsafe language like C, C++; but without having source code)? I don't mean simple bypass-able sandbox, or anti-virus software.
I think about two possibilities:
- run application as different OS user, set restrictions for this user. Disadvantage - many users, for every combination of parameters, access rights?
- (somehow) limit (OS API) functions, that can be called
I don't know if any of possibilities allow (at least in theory) in full protection, without possibility of bypass.
Edit: I'm interested more in theory - I don't care that e.g. some OS has some undocumented functions, or how to sandbox any application on given OS. For example, I want to sandbox application and allow only two functions: get char from console, put char to console. How is it possible to do it unbreakably, no possibility of bypassing?
Answers mentioned:
- Google Native Client, uses subset of x86 - in development, together with (possible?) PNaCl - portable native client
- full VM - obviously overkill, imagine tens of programs...
In other words, could native (unsafe memory access) code be used within restricted environment, e.g. in web browser, with 100% (at least in theory) security?
Edit2: Google Native Client is exactly what I would like - any language, safe or unsafe, run at native speed, sandbox, even in web browser. Everybody use whatever language you want, in web or on desktop.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可能想了解 Google 的 Native Client，它运行 x86 代码（我相信现在还有 ARM 代码） ）在沙箱中。
You might want to read about Google's Native Client which runs x86 code (and ARM code I believe now) in a sandbox.
您在最初的问题中几乎描述了 AppArmor 。有相当一些很好的视频解释了它，我强烈推荐观看。
You pretty much described AppArmor in your original question. There are quite a few good videos explaining it which I highly recommend watching.
可能的？是的。难的？也是的。依赖于操作系统？非常是的。
大多数现代操作系统都支持各种级别的进程隔离，可用于实现您想要的目的。最简单的方法是简单地附加一个调试器并在所有系统调用上中断；然后在调试器中过滤这些调用。然而，这会对性能造成很大影响，并且在存在多个线程的情况下很难确保安全。在没有记录低级系统调用接口的操作系统（例如 Mac OS 或 Windows）上安全地实现也很困难。
Chrome 浏览器的开发人员在这个领域做了很多工作。他们发布了 Windows、Linux（特别是 SUID 沙箱)，以及 Mac OS X。他们的方法是有效的，但并非完全万无一失——外部操作系统和来宾应用程序之间仍然可能存在一些较小的信息泄漏。此外，某些操作系统需要对来宾程序进行特定修改才能在沙箱之外进行通信。
如果可以接受对托管应用程序的一些修改，那么 Google 的本机客户端值得一看。这限制了编译器的代码生成选择，使得加载程序可以证明它没有做任何令人讨厌的事情。这显然不适用于任意可执行文件，但它会给您带来本机代码的性能优势。
最后，您始终可以在模拟器中简单地运行相关程序以及整个操作系统。这种方法基本上是万无一失的，但会增加大量的开销。
Possible? Yes. Difficult? Also yes. OS-dependent? Very yes.
Most modern OSes support various levels of process isolation that can be used to acheive what you want. The simplest approach is to simply attach a debugger and break on all system calls; then filter these calls in the debugger. This, however, is a large performance hit, and is difficult to make safe in the presence of multiple threads. It is also difficult to implement safely on OSes where the low-level syscall interface is not documented - such as Mac OS or Windows.
The Chrome browser folks have done a lot of work in this field. They've posted design docs for Windows, Linux (in particular the SUID sandbox), and Mac OS X. Their approach is effective but not totally foolproof - there may still be some minor information leaks between the outer OS and the guest application. In addition, some of the OSes require specific modifications to the guest program to be able to communicate out of the sandbox.
If some modification to the hosted application is acceptable, Google's native client is worth a look. This restricts the compiler's code generation choices in such a way that the loader can prove that it doesn't do anything nasty. This obviously doesn't work on arbitrary executables, but it will get you the performance benefits of native code.
Finally, you can always simply run the program in question, plus an entire OS to itself, in an emulator. This approach is basically foolproof, but adds significant overhead.
是的，如果硬件提供限制内存访问的机制，这是可能的。桌面处理器通常配备有 MMU 和访问级别，因此操作系统可以利用它们来拒绝访问线程不应访问的任何内存地址。
虚拟内存是通过完全相同的方式实现的：对当前换出到磁盘的内存的任何访问都会被捕获，从磁盘获取内存，然后线程继续。虚拟化更进一步，因为它还捕获对硬件寄存器的访问。
操作系统真正需要做的就是正确使用这些功能，任何代码都不可能突破沙箱。当然，这说起来容易做起来难。主要是因为操作系统在有利于性能的情况下采取了自由，对某些操作系统调用的用途进行了监督，最后但并非最不重要的是实现中的错误。
Yes this is possible IF the hardware provides mechanisms to restrict memory accesses. Desktop processors usually are equipped with an MMU and access levels, so the OS can employ these to deny access to any memory address a thread should not have access to.
Virtual memory is implemented by the very same means: any access to memory currently swapped out to disk is trapped, the memory fetched from disk and then the thread is continued. Virtualization takes it a little farther, because it also traps accesses to hardware registers.
All the OS really needs to do is properly use those features and it will be impossible for any code to break out of the sandbox. Of course this much easier said than practically applied. Mostly because the OS takes liberties if favor of performance, oversights in what certain OS calls can be used to do and last but not least bugs in the implementation.