1. 介绍
 
1.1 简介
 
JVM-SANDBOX（沙箱）实现了一种在不重启、不侵入目标JVM应用的AOP解决方案。Sandbox仅仅是提供一个无侵入的入口，至于将Sandbox作用于何处，是需要额外去定义的，例如Sandbox-Repeater就是集成Sandbox使用的流量回放框架（坑）。
 
1.2 特性
 
无侵入：目标应用无需重启也无需感知沙箱的存在
类隔离：沙箱以及沙箱的模块不会和目标应用的类相互干扰
可插拔：沙箱以及沙箱的模块可以随时加载和卸载，不会在目标应用留下痕迹
多租户：目标应用可以同时挂载不同租户下的沙箱并独立控制
高兼容：支持JDK[6,11]
1.3 原理
 
1.3.1  Java agent介绍
 
（1）什么是Java agent
 
java agent本质上可以理解为一个插件，该插件就是一个精心提供的jar包，这个jar包通过JVMTI（JVM Tool Interface）完成加载，最终借助JPLISAgent（Java Programming Language Instrumentation Services Agent）完成对目标代码的修改。
 
（2）功能
 
 
可以在加载java文件之前做拦截把字节码做修改
 
 
可以在运行期将已经加载的类的字节码做变更
 
 
还有其他的一些小众的功能
 
  
 
获取所有已经被加载过的类
 
 
获取所有已经被初始化过了的类
 
 
获取某个对象的大小
 
 
将某个jar加入到bootstrapclasspath里作为高优先级被bootstrapClassloader加载
 
 
将某个jar加入到classpath里供AppClassloard去加载
 
 
设置某些native方法的前缀，主要在查找native方法的时候做规则匹配
 
（3） 实现agent启动方法
 
Java Agent支持目标JVM启动时加载，也支持在目标JVM运行时加载，这两种不同的加载模式会使用不同的入口函数，如果需要在目标JVM启动的同时加载Agent，那么可以选择实现下面的方法：
 
[1] public static void premain(String agentArgs, Instrumentation inst); 
[2] public static void premain(String agentArgs);
 
JVM将首先寻找[1]，如果没有发现[1]，再寻找[2]。如果希望在目标JVM运行时加载Agent，则需要实现下面的方法：
 
[1] public static void agentmain(String agentArgs, Instrumentation inst); 
[2] public static void agentmain(String agentArgs);
 
（4）指定Main-Class
 
<build>
        <finalName>xxx-${project.version}</finalName>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-assembly-plugin</artifactId>
                <executions>
                    <execution>
                        <goals>
                            <goal>attached</goal>
                        </goals>
                        <phase>package</phase>
                        <configuration>
                            <descriptorRefs>
                                <descriptorRef>jar-with-dependencies</descriptorRef>
                            </descriptorRefs>
                            <archive>
                                <manifestEntries>
                                    <Premain-Class>com.alibaba.jvm.sandbox.agent.AgentLauncher</Premain-Class>
                                    <Agent-Class>com.alibaba.jvm.sandbox.agent.AgentLauncher</Agent-Class>
                                    <Can-Redefine-Classes>true</Can-Redefine-Classes>
                                    <Can-Retransform-Classes>true</Can-Retransform-Classes>
                                </manifestEntries>
                            </archive>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
 
（5）agent加载
 
 
启动时加载
 
  
 
启动参数增加-javaagent:[path]，其中path为对应的agent的jar包路径
 
 
运行中加载
 
  
 
使用com.sun.tools.attach.VirtualMachine加载
 
try {
  String jvmPid = 目标进行的pid;
  logger.info("Attaching to target JVM with PID: " + jvmPid);
  VirtualMachine jvm = VirtualMachine.attach(jvmPid);
  jvm.loadAgent(agentFilePath);//agentFilePath为agent的路径
  jvm.detach();
  logger.info("Attached to target JVM and loaded Java agent successfully");
} catch (Exception e) {
  throw new RuntimeException(e);
}
 
 1.4 Sandbox和Arthas
 
TBD
 
2. 源码
 
3. FAQ
 
3.1 jar-with-dependencies
 
 
 
4. 参考资料
 
【jvm-sandbox】

学习uboot sandbox
 
1.Sandbox
 
  The ‘sandbox’ architecture is designed to allow U-Boot to run under Linux on almost any hardware. To achieve this it builds U-Boot (so far as possible) as a normal C application with a main() and normal C libraries.
 
  All of U-Boot’s architecture-specific code therefore cannot be built as part of the sandbox U-Boot. The purpose of running U-Boot under Linux is to test all the generic code, not specific to any one architecture. The idea is to create unit tests which we can run to test this upper level code.
 
Sandbox configurations includes:
 
CONFIG_SANDBOX
CONFIG_SANDBOX_BIG_ENDIAN
 
There are two versions of the sandbox:
 
32-bit-wide integers
64-bit-wide integers.
 
  Note：by default, the sandbox it built for a 32-bit host. The sandbox using 64-bit-wide integers can only be built on 64-bit hosts.
 
2.Basic Operation
 
  To run sandbox U-Boot use something like:
 
 $make sandbox_defconfig all
 $./u-boot
 
Note: If you get errors about ‘sdl-config: Command not found’ you may need to install libsdl1.2-dev or similar to get SDL support. Alternatively you can build sandbox without SDL (i.e. no display/keyboard support) by removing the CONFIG_SANDBOX_SDL line in include/configs/sandbox.h or using:
 
#Some machines do not have SDL libraries installed, and it is still useful to build sandbox without LCD/keyboard support.
$sudo apt-get install libsdl1.2-dev
$make sandbox_defconfig all NO_SDL=1
$./u-boot
 
U-Boot will start on your computer, showing a sandbox emulation of the serial
console:
U-Boot 2014.04 (Mar 20 2014 - 19:06:00)
DRAM:  128 MiB
Using default environment

In:    serial
Out:   lcd
Err:   lcd
=>
 
  You can issue commands as your would normally. If the command you want is not supported you can add it to include/configs/sandbox.h.
 
  To exit, type ‘reset’ or press Ctrl-C.
 
  You can use the test-dm.sh：
 
  1 #!/bin/sh
  2 
  3 die() {
  4     echo $1
  5     exit 1
  6 }
  7 
  8 NUM_CPUS=$(cat /proc/cpuinfo |grep -c processor)
  9 make O=sandbox sandbox_config  || die "Cannot configure U-Boot"
 10 make O=sandbox -s -j${NUM_CPUS} || die "Cannot build U-Boot"
 11 
 12 dd if=/dev/zero of=spi.bin bs=1M count=2
 13 echo -n "this is a test" > testflash.bin
 14 dd if=/dev/zero bs=1M count=4 >>testflash.bin
 17 ./sandbox/u-boot -d sandbox/arch/sandbox/dts/test.dtb -i "dm test"        
 18 #./sandbox/u-boot -d sandbox/arch/sandbox/dts/test.dtb -c "dm test"                                                                                    
 19 rm -f spi.bin
 20 rm -f testflash.bin
 
Note:
   To execute commands directly, use the -c option. When -c is used, U-Boot exits after the command is complete,but you can force it to go to interactive mode instead with -i.
 
You can use the command below：
 
Documents/work/code/u-boot/u-boot$ ./sandbox/u-boot -help
U-Boot 2019.07-rc3-dirty (May 31 2019 - 19:10:05 +0800)

u-boot, a command line test interface to U-Boot

Usage: u-boot [options]
Options:
      --show_of_platdata         Show of-platdata in SPL
  -L, --log_level        <arg>   Set log level (0=panic, 7=debug)
  -v, --verbose                  Show test output
  -t, --terminal         <arg>   Set terminal to raw/cooked mode
  -l, --show_lcd                 Show the sandbox LCD display
  -n, --ignore_missing           Ignore missing state on read
  -w, --write                    Write state FDT on exit
  -r, --read                     Read the state FDT on startup
  -s, --state            <arg>   Specify the sandbox state FDT
      --rm_memory                Remove memory file after reading
  -m, --memory           <arg>   Read/write ram_buf memory contents from file
  -j, --jump             <arg>   Jumped from previous U-Boot
  -i, --interactive              Enter interactive mode
  -D, --default_fdt              Use the default u-boot.dtb control FDT in U-Boot directory
  -d, --fdt              <arg>   Specify U-Boot's control FDT
  -c, --command          <arg>   Execute U-Boot command
  -b, --boot                     Run distro boot commands
  -h, --help                     Display help

 
2.1.Console / LCD support
 
  Assuming that CONFIG_SANDBOX_SDL is defined when building, you can run the sandbox with LCD and keyboard emulation, using something like:
 
 
 
./u-boot -d u-boot.dtb -l
 Note : -l causes the LCD emulation window to be shown.
 
 
  This will start U-Boot with a window showing the contents of the LCD. If that window has the focus then you will be able to type commands as you would on the console. You can adjust display settings in the device tree file - arch/sandbox/dts/sandbox.dts.
 
3.Supported Drivers
 
 174U-Boot sandbox supports these emulations:
 175
 176- Block devices
 177- Chrome OS EC
 178- GPIO
 179- Host filesystem (access files on the host from within U-Boot)
 180- I2C
 181- Keyboard (Chrome OS)
 182- LCD
 183- Network
 184- Serial (for console only)
 185- Sound (incomplete - see sandbox_sdl_sound_init() for details)
 186- SPI
 187- SPI flash
 188- TPM (Trusted Platform Module)
 
There are unfortunately quite a few variants at present:
 
There are unfortunately quite a few variants at present:
 200
 201 sandbox - should be used for most tests
 202 sandbox64 - special build that forces a 64-bit host
 203 sandbox_flattree - builds with dev_read_...() functions defined as inline.
 204    We need this build so that we can test those inline functions, and we
 205    cannot build with both the inline functions and the non-inline functions
 206    since they are named the same.
 207 sandbox_noblk - builds without CONFIG_BLK, which means the legacy block
 208    drivers are used. We cannot use both the legacy and driver-model block
 209    drivers since they implement the same functions
 210 sandbox_spl - builds sandbox with SPL support, so you can run spl/u-boot-spl
 211    and it will start up and then load ./u-boot. It is also possible to
 212    run ./u-boot directly.
 
4.Testing
 
  U-Boot sandbox can be used to run various tests, mostly in the test/ directory. These include:
 
 401  command_ut
 402     - Unit tests for command parsing and handling
 403  compression
 404     - Unit tests for U-Boot's compression algorithms, useful for
 405       security checking. It supports gzip, bzip2, lzma and lzo.
 406  driver model
 407     - Run this pytest
 408          ./test/py/test.py --bd sandbox --build -k ut_dm -v
 409  image
 410     - Unit tests for images:
 411          test/image/test-imagetools.sh - multi-file images
 412          test/image/test-fit.py        - FIT images
 413  tracing
 414     - test/trace/test-trace.sh tests the tracing system (see README.trace)
 415  verified boot
 416      - See test/vboot/vboot_test.sh for this
 417
 
Note： To run all tests use “make check”.
 
5.Related code about the sandbox:
 
include/configs/sandbox.h
arch/sandbox/
board/sandbox/
test/dm/
 
参考资料：
 https://lxr.missinglinkelectronics.com/uboot/board/sandbox/README.sandbox

 
Sandbox FAQ
 
What is the sandbox?
What does and doesn't it protect against?
Is the sandbox like what you get with the Java VM?
How can you do this for C++ code if there is no virtual machine?
Doesn't Vista have similar functionality?
Isn't that a lot of work?
Should I be aware of any gotchas?
How about COM, Winsock, or DirectX — can I use them?
What do you mean by before lock-down? Is the sandboxed process not locked down from the start?
So what APIs can you call?
But can't malware just infect the process at the other end of the pipe or shared memory?
 

 
What is the sandbox?
 
The sandbox is a C++ library that allows the creation of sandboxed processes — processes that execute within a very restrictive environment. The only resources sandboxed processes can freely use are CPU cycles and memory. For example, sandboxes processes cannot write to disk or display their own windows. What exactly they can do is controlled by an explicit policy. Chromium renderers are sandboxed processes.
 
What does and doesn’t it protect against?
 
The sandbox limits the severity of bugs in code running inside the sandbox. Such bugs cannot install persistent malware in the user‘s account (because writing to the filesystem is banned). Such bugs also cannot read and steal arbitrary files from the user’s machine.
 
(In Chromium, the renderer processes are sandboxed and have this protection. After the NPAPI removal, all remaining plugins are also sandboxed. Also note that Chromium renderer processes are isolated from the system, but not yet from the web. Therefore, domain-based data isolation is not yet provided.).
 
The sandbox cannot provide any protection against bugs in system components such as the kernel it is running on.
 
Is the sandbox like what you get with the Java VM?
 
Yeah, kind of… except that to take advantage of the Java sandbox, you must rewrite your code to use Java. With our sandbox you can add sandboxing to your existing C/C++ applications. Because the code is not executed inside a virtual machine, you get native speed and direct access to the Windows API.
 
Do I need to install a driver or kernel module? Does the user need to be Administrator?
 No and no. The sandbox is a pure user-mode library, and any user can run sandboxed processes.
 
How can you do this for C++ code if there is no virtual machine?
 
We leverage the Windows security model. In Windows, code cannot perform any form of I/O (be it disk, keyboard, or screen) without making a system call. In most system calls, Windows performs some sort of security check. The sandbox sets things up so that these security checks fail for the kinds of actions that you don’t want the sandboxed process to perform. In Chromium, the sandbox is such that all access checks should fail.
 
So how can a sandboxed process such as a renderer accomplish anything?
 Certain communication channels are explicitly open for the sandboxed processes; the processes can write and read from these channels. A more privileged process can use these channels to do certain actions on behalf of the sandboxed process. In Chromium, the privileged process is usually the browser process.
 
Doesn’t Vista have similar functionality?
 
Yes. It’s called integrity levels (ILs). The sandbox detects Vista and uses integrity levels, as well. The main difference is that the sandbox also works well under Windows XP. The only application that we are aware of that uses ILs is Internet Explorer 7. In other words, leveraging the new Vista security features is one of the things that the sandbox library does for you.
 
This is very neat. Can I use the sandbox in my own programs?
 Yes. The sandbox does not have any hard dependencies on the Chromium browser and was designed to be used with other Internet-facing applications. The main hurdle is that you have to split your application into at least two interacting processes. One of the processes is privileged and does I/O and interacts with the user; the other is not privileged at all and does untrusted data processing.
 
Isn’t that a lot of work?
 
Possibly. But it‘s worth the trouble, especially if your application processes arbitrary untrusted data. Any buffer overflow or format decoding flaw that your code might have won’t automatically result in malicious code compromising the whole computer. The sandbox is not a security silver bullet, but it is a strong last defense against nasty exploits.
 
Should I be aware of any gotchas?
 
Well, the main thing to keep in mind is that you should only sandbox code that you fully control or that you fully understand. Sandboxing third-party code can be very difficult. For example, you might not be aware of third-party code’s need to create temporary files or display warning dialogs; these operations will not succeed unless you explicitly allow them. Furthermore, third-party components could get updated on the end-user machine with new behaviors that you did not anticipate.
 
How about COM, Winsock, or DirectX — can I use them?
 
For the most part, no. We recommend against using them before lock-down. Once a sandboxed process is locked down, use of Winsock, COM, or DirectX will either malfunction or outright fail.
 
What do you mean by before lock-down? Is the sandboxed process not locked down from the start?
 
No, the sandboxed process does not start fully secured. The sandbox takes effect once the process makes a call to the sandbox method LowerToken(). This allows for a period during process startup when the sandboxed process can freely get hold of critical resources, load libraries, or read configuration files. The process should call LowerToken() as soon as feasible and certainly before it starts interacting with untrusted data.
 
Note: Any OS handle that is left open after calling LowerToken() can be abused by malware if your process gets infected. That’s why we discourage calling COM or other heavyweight APIs; they leave some open handles around for efficiency in later calls.
 
So what APIs can you call?
 
There is no master list of safe APIs. In general, structure your code such that the sandboxed code reads and writes from pipes or shared memory and just does operations over this data. In the case of Chromium, the entire WebKit code runs this way, and the output is mostly a rendered bitmap of the web pages. You can use Chromium as inspiration for your own memory- or pipe-based IPC.
 
But can’t malware just infect the process at the other end of the pipe or shared memory?
 
Yes, it might, if there‘s a bug there. The key point is that it’s easier to write and analyze a correct IPC mechanism than, say, a web browser engine. Strive to make the IPC code as simple as possible, and have it reviewed by others.

 
沙箱 sandbox
 
1. 沙箱定义
1.1 apt 攻击
  
2. 沙箱防御攻击的过程
3. 沙箱 明显的缺点：

 
1. 沙箱定义
 
沙箱技术是防御apt攻击的最有效的方法之一，通过沙箱技术构造一个隔离的威胁
 检测环境，然后将网络流量送入沙箱进行隔离分析并最终给出是否存在威胁的结论。如果沙箱检测到某流量为恶意流量，FW则对流量实施阻断。
 
1.1 apt 攻击
 
Advanced Persistent Threat
APT攻击，即高级可持续威胁攻击,也称为定向威胁攻击，
 指某组织对特定对象展开的持续有效的攻击活动。
 
2. 沙箱防御攻击的过程
 
外网的攻击者向企业内网发起APT攻击，命中APT防御配置文件的攻击流量将被还原成文件。
FW将还原后的文件送往沙箱进行威胁分析。
FW定期去沙箱上获取文件的检测结果，根据检测结果实施相应的动作。
如果沙箱分析出该文件是一种恶意攻击文件，FW则对具有相同特征的后续流量实施阻断操作，防止该流量进入企业内网，保护企业内网免遭攻击。
 
3. 沙箱 明显的缺点：
 
做不到实时阻断
稍微改动就检查不了