Java 沙盒环境与 C 的对比
Java 被设计为在“沙盒”环境中运行，而 C 则不受限制。从安全角度讨论这一点的含义。
我对这个概念做了一些研究。我发现，如果 Java 运行的地方被沙箱化，它就会通过一个更受控制的门来从内存的不同部分检索信息。然而，在 C 语言中，不受控制的情况则不然。
有人可以解释一下我是否还可以添加其他内容吗？
编辑：
这就是我添加的内容：
Java 编程语言是一种面向对象的语言，专门设计为具有尽可能少的实现依赖性。 Java是一次编写部署多次的模型。它表面上类似于 C/C++/C#，但具有不同的底层对象模型。 Java 有很多版本，例如 Java 标准版（Java SE）、Java 移动版（Java ME）、Java 企业版（Java EE）等。
用 java 编写的应用程序被编译为 Java 字节码，Java 字节码是独立于中间语言的任何平台的。因此，编译器可以跨平台工作。
编译和执行的虚拟机模型通过在 Java 虚拟机 (JVM) 上运行编译后的代码（Java 字节代码）来工作。 Java虚拟机解释Java字节码并提供Java字节码可以执行的环境。所有平台上的所有 JVM 使用相同的字节码，这使得 Java 可以被描述为“一次编写，随处运行”。
由于以下原因，这是比生成本机代码的编译器更好的模型：
移动设备具有各种形状和尺寸，并且具有不同的处理器速度和体系结构。因此，一旦设备上实现了 JVM，编译和执行的虚拟机模型就允许所有 Java 应用程序运行在各种不同的移动平台上。
虚拟机编译模式提供了一个独立于平台的编程环境，它抽象了底层硬件或操作系统的细节，并允许程序在任何平台上以相同的方式执行。
与编译型编程语言相当的性能是通过使用即时编译（一种提高计算机程序运行时性能的方法）来实现的。
从字节代码编译到机器代码比从源代码编译要快得多。
与本机代码不同，部署的字节代码是可移植的。
由于运行时可以控制编译，就像解释的字节代码一样，它可以在安全沙箱中运行。从字节码到机器码的编译器更容易编写，因为可移植字节码编译器已经完成了大部分工作。
Java is designed to run in a “Sandboxed” environment in contrast to C which is not constrained. Discuss the implications of this from a security point of view.
I have done a bit of research in regards to the concept. What I found was if it's sandboxed where Java runs on, it goes through a more controlled door to retrieve information from different parts of memory. However, in C, it doesn't where it is uncontrolled.
Can someone please explain if there is anything else that I can add?
Edit:
This is what I have added:
Java programming language is an object-oriented language specifically designed to have as few implementation dependencies as possible. Java is write once deploy many times model. It is superficially like C/C++/C# but have different underlying object model. There are many versions of Java such as Java Standard Edition (Java SE), Java Mobile Edition (Java ME), Java Enterprise Edition (Java EE) etc.
The applications written in java are compiled to Java byte code which is an intermediate language independent of any platform. Thus, compiler can work multi platform.
The Virtual Machine model of compilation and execution works by running the compiled code (Java byte code) on Java Virtual Machine (JVM). Java Virtual Machine interprets java byte code and provides an environment in which Java byte code can be executed. The use of the same byte code for all JVMs on all platforms allow Java to be described as a “write once, run anywhere”.
This is better model than the compiler that generates native code due to following reasons:
Mobile devices come in various shape and sizes and with varying processor speed and architecture. Therefore, the virtual machine model of compilation and execution allows all java apps to run on various different mobile platforms once JVM is implemented on a device.
The virtual machine mode of compilation provide a platform-independent programming environment that abstracts away details of the underlying hardware or operating system, and allows a program to execute in the same way on any platform.
Performance comparable to compiled programming languages is achieved by the use of just-in-time compilation (a method to improve the runtime performance of computer program).
Compilation from byte code to machine code is much faster than compiling from source.
The deployed byte code is portable, unlike native code.
Since the runtime has control over the compilation, like interpreted byte code, it can run in a secure sandbox. Compilers from byte code to machine code are easier to write, because the portable byte code compiler has already done much of the work.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不要混合语言和虚拟化。
例如，Google 的 Native Client (NaCL) 是 C/C++（以及其他所有）程序的沙盒环境。
Don't mix languages and virtualisation.
Google's Native Client (NaCL) is a sandboxed environment for C/C++ (and everything else) programs, for example.
以下是我突发奇想的沙盒代码最常见安全挑战的“快速抽样”。
在沙盒应用程序中。将在以下领域添加限制：
System.exit(n)。user.*、任意数量的java.*属性）机器人。如果这个问题是关于“安全”的，那么您需要做很多研究。 ;)
Here is a 'quick sampling' of the most common security challenges for sand-boxed code, off the top of my head.
In a sand-boxed app. restrictions will be added in the areas of:
System.exit(n).user.*, any number ofjava.*props)Robot.If this question is about 'security', you have a lot of research to do. ;)
Java 本质上是“可沙箱”的，而 C++ 等则不然。在 Java 中，没有办法到达对象之外——例如，您不能自由地将对象指针转换为 char*，并且不能寻址到数组末尾之外。
对系统设施的访问受到多种方式的限制（其中一些我现在忘记了）。但基本上，人们可以运行一个加载安全类加载器等的 Java 程序，然后在该环境中加载的任何应用程序都会被“围住”，并且无法执行您不希望让它执行的任何操作。
（事实上，IBM iSeries 上的“经典”JVM 利用这些功能来防止“主”Java 程序疯狂运行。Java 代码与操作系统运行在相同的地址空间中，但操作系统仍然受到 Java 的保护固有的安全性。）
在 C++ 等中，为了完成同样的事情，您要么必须使用存储保护硬件，要么拥有一个编译器来检查每次访问进行编译。
Java is inherently "sandboxable", whereas C++ et al are not. In Java there is no way to get outside of an object -- you can't freely cast an object pointer to
char*, for instance, and you can't address beyond the end of an array.Access to system facilities is limited by in several ways (some of which I forget just now). But basically one can run a Java program that loads secure class loaders and the like, and then any application that is loaded in that environment is "corralled" and cannot do anything that you don't wish to let it do.
(In fact, the "classic" JVM on IBM iSeries made use of these features to prevent even the "main" Java program from running amok. Java code ran in the same address space as the OS, but still the OS was protected by Java's inherent security.)
In C++ et al, in order to accomplish the same thing, you either have to make use of storage protection hardware or else have a compiler that compiles in checks of every access.