About Chrome sandbox Technology (sandbox Technology)

Apple's. plist reads and writes are similar to the sandbox technology.

Baidu, Google, said Chrome is a browser security standard, using the "sandbox" stuff, collected some information, summarized as follows:

The sandbox is actually a hard disk filter file driver. Specifically, you write the content you want to write to the hard disk, but it is not actually written to the hard disk, but to a transfer location, to read the content, you need to determine whether the content exists before the sandbox is enabled or the content written after the sandbox is enabled. You need to read the content from different places, and then reset the transfer location after restart.

File filter driver writing and loading methods (bitmap, keyword found on the Internet): is a small block of a small slice, each bit of Bitmap corresponds to a sector on the disk, n-bits have n sectors. If this bit is 0, the data in this sector is not stored elsewhere. If it is 1, it is stored elsewhere, set bitmap to 1 during write and read from the shard where bitmap is 1. If it is 0, the data is still read from the original device, after restarting, bitmap returns to all 0.

Google native client is a specific application of sandbox. The following describes the design concept:

System Architecture 

One NaCl ApplicationProgramIt consists of many trusted and untrusted NaCl modules, each of which runs independently in a process. Assume that an application based on NaCl is used to manage and share images. It consists of two components, a user interface implemented by JavaScript, and runs in a web browser, the other is the image processing library, which is implemented as a native client module. In this scenario, both are untrusted. Browser components are restricted by the browser execution environment, while image processing libraries are restricted by the native client container. Before running this image application, you must install the native client as a browser plug-in. We regard it as a trusted NaCl module.

When a user accesses the web site of our image application, the browser loads and executes the Javascript component of the application, the latter loads the image processing Library to the native client container through the native client plug-in. The loading process does not jump out of the prompt window. The native client is responsible for limiting the behavior of the local application module.

Each component runs in its private address space. Inter-component communication is implemented through the reliable packet service of NaCl-Inter-module communication (IMC. NaCl provides two methods for communication between browsers and the NaCl module: simple remote process call (srpc) and Netscape plug-in application interface (npapi), both of which are implemented based on IMC. To avoid the message burden caused by high-frequency communication, IMC also provides shared memory segments and shared synchronization objects.

The NaCl module can also access"ServiceIt provides memory management operations, creating threads and other system services. This interface is similar to the system calling interface of the operating system. The application can contain multiple native client modules, and both trusted and untrusted modules can use IMC. For example, users of the image application mentioned above can choose to install a trusted NaCl service for local image storage. Because it can access the local hard disk, this storage service must be installed as a local browser plug-in and cannot be implemented as a native client module. During application initialization, the user interface checks whether the storage service is available. If it is available, it establishes an IMC communication channel with it, and pass the descriptor of the communication channel to the image processing library. Instead, the two can communicate directly through the IMC-based service (srpc, shared memory, etc. In this case, the NaCl module is generally statically linked to a library responsible for providing process interfaces to access the storage service. This library encapsulates the communication details at the IMC layer, in this way, you do not need to worry about whether the underlying layer uses srpc or shared memory. The storage service component assumes that the image processing library is untrusted and ensures that only services that comply with the interface contract are executed.

Components similar to the above storage service are generally implemented outside the NaCl kernel, which is similar to the micro-kernel model of the operating system, which is simple, stable, and loosely coupled.

The following describes in detail the design of each component of the NaCl system.

Internal and external two-layer sandbox 

The native client is built based on the "inner sandbox" in the x86 process. To further defend against attacks, an "outer sandbox" is also built to isolate process boundaries.

Inner sandbox usageCodeStatic analysis technology checks security risks in untrusted x86 code. In the past, such analysis was challenged by many technical challenges, such as self-modifiable code and overlapping commands. To solve this problem, a series of contract and structure rules are developed for the code in the native client to ensure that the local code module can be reliably decomposed, then, the Code validators are used to ensure that the executable file only contains commands in the valid instruction set.

The inner sandbox also uses the x86 memory segmentation mechanism to restrict the memory reference of data and commands.

The inner sandbox is used to create a secure subdomain in a local process. In this subdomain, we can place a trusted service runtime subsystem and untrusted module in the same process. A secure skip/split board mechanism is used to allow control transfer between trusted code and Untrusted code.

The inner sandbox not only separates the system from the local module, but also separates the local module from the operating system.

The outer sandbox is the second defense mechanism. It rejects or uses all system calls of processes running the NaCl module by comparing them with an Allowed System Call whitelist. Currently, 46 system calls are allowed on the whitelist.

Runtime Mechanism

The IMC allows trusted and untrusted modules to send/receive data packets containing a non-byte array across process boundaries. It can also contain file sharing and shared memory objects, the "NaCl resource descriptor" of the communication channel. The first method is srpc, which is used to define and use sub-processes to access cross-module boundaries, including calling the NaCl code from Javascript in the browser. The second is the npapi, which provides interfaces for interaction with the browser status, including opening URLs and accessing the Dom. These two mechanisms can be used to interact with browsers, including page content modification, processing mouse and keyboard events, and obtaining other site content, because they can be accessed through JavaScript.

As mentioned above, the runtime Service is responsible for providing containers for interaction between the NaCl module and the browser. It generally provides a series of system services that adapt to the application programming environment. To support the malloc/free interface or other memory allocation abstraction mechanisms, it provides sbrk () and MMAP () system calls. It provides a subset of POSIX thread interfaces for thread creation and destruction, conditional variables, mutex, semaphores, and local thread storage. It also provides common POSIX file I/O interfaces for communication channels and web-based read-only content operations. To prevent malicious network access, system calls such as connect () and accept () are unavailable.

Attack Layer

Attackers may pay attention to the following aspects:

1) Inner sandbox: Binary Verification

2) Outer sandbox: OS system call interception

3)ServiceRuntime binary module Loader

4)ServiceRuntime jump Interface

5) IMC Communication Interface

6) npapi

In addition to the internal and external sandbox, the system also includes the whitelist mechanism of CPU and NaCl modules.

The following describes the detailed implementation details of each component.

Inner sandbox

This layer is limited to the obvious control flow (call and jump) in machine code ). Other types of control flow (such as exceptions) are processed in the service during the NaCl runtime.

The inner sandbox defines a series of rules for reliable decomposition, a compilation toolchain for monitoring these rules, and a static Code Analyzer to ensure that the Code complies with the rules, the three methods are used to check the credibility of the Code.

Binary Code rules of the NaCl module:

C1 Once loaded into the memory, the binary is not writable,
Enforced by OS-level protection mechanisms during execution.
C2 the binary is statically linked at a start address of zero, with the first byte of text at 64 K.
C3 all indirect control transfers use a nacljmp pseudo-instruction (defined below ).
C4 the binary is padded up to the nearest page with
One hlt instruction (0xf4 ).
C5 the binary contains no instructions or pseudo-instructions overlapping a 32-byte boundary.
C6 all valid instruction addresses are reachable by a fall-through disassembly that starts at the load (base) address.

C7 all direct control transfers target valid instructions.

Use section 80386 to restrict data references in consecutive sub-segments in the virtual 32-bit address space. At the same time, it is forbidden to use some operation codes, such as syscall and INT (the system call cannot be directly called without Trusted code), all commands for modifying the status of X86 segments (such as LDs), and ret. The HLT command is allowed, but it causes the module to terminate immediately. For security consideration, all other commands with a level 0 privilege are also prohibited, because they should not be used in a correct user-mode command stream. (Other details are too obscure)

We found that the validators used can check the code at a speed of 30 Mb/s, which is very small compared with the downloaded data, so it will not cause performance problems.

Outer sandbox

If the memory sandbox is broken, untrusted code can access the runtime service. However, the outer sandbox can control system calls at the process boundary to prevent most dangerous behaviors. The implementation on Linux uses the ptrace interface. On Windows, the access control list will be used (currently, only the implementation on Linux is available, and Mac and windows are still under development ).

In Linux, the implementation starts the NaCl container as a sub-process, and then uses ptrace to check all system calls sent by the process. The outer sandbox maintains a allowed whitelist of system calls. Attempting to execute any calls other than the whitelist will immediately end the NaCl module.

However, the current implementation of ptrace increases the burden on each system call, because even if it is in the whitelist, it will perform two context switches and one query table, to determine whether the call is allowed. Therefore, the system performance may be affected. Developers must be cautious when using system calls and minimize the frequency of Inter-module communication. You can consider using shared memory and synchronization objects, this is important for applications with High Access frequency and high bandwidth communication to achieve optimal performance.

Exception

Hardware exceptions (segment errors, floating point errors) and external interruptions are not allowed. To isolate exceptions, each NaCl module runs in a separate process and cannot be recovered from the hardware exception using exception handling. Instead, the process is disabled. Although hardware exceptions are not supported, C ++ exceptions are indeed supported, Windows wseh is not supported ).

Service runtime

A service is a local executable code called by an npapi plug-in that supports interaction between the service runtime and the browser. It implements the dynamic enforcement mechanism, which maintains the integrity of the inner sandbox and provides a resource abstraction layer, thus separating the NaCl application from host resources and operating system interfaces. It contains trusted code and data, but shares the same process with the contained NaCl module, and the latter can access service runtime through a controlled interface. When the service is running, the x86 memory segmentation and paging mechanisms are used together to prevent unauthorized code access to the memory.

When an NaCl module is loaded in, it is placed in a m area separated by the middle section of the address space during service running. The first 64 KB of the address space (NaCl "user" Space) of the NaCl module is retained during service running and used for initialization. The first 4 kb is read/write protected and used to check the NULL pointer. The remaining 60 kb contains a trusted code segment that implements "jumping" call gate and "scorecard" Return door. Untrusted NaCl modules are loaded immediately after 64 KB.

(Note: each native plug-in process contains a piece of code called service runtime, which is used to simulate the traditional system call, the system call of plug-in is redirected to the service runtime in the process, that is, switching from untrust code to trust code. After entering the service runtime, the system restores the familiar flat memory addressing to access the operating system resources. Of course, only a few secure system calls are processed by service runtime. Static analysis in the first level sandbox ensures that the unstruct native code cannot enter the service runtime at will .)

Communication

IMC is the basis for communication between NaCl modules. It is implemented based on the NaCl socket and provides a bidirectional, reliable, and ordered data packet service similar to the Unix domain socket. When an untrusted NaCl module is created (created through DOM and JavaScript), it receives the first NaCl socket. Javascript uses this socket to send messages to the NaCl module. It can also be shared with other NaCl modules. Javascript can also share the NaCl socket as the NaCl descriptor to connect the module to other services. The NaCl descriptor can also be used to create shared memory segments.

By using the NaCl message, the srpc of the NaCl is fully implemented in Untrusted code. Srpc can be used to define the process interface between JavaScript and NaCl modules or between two NaCl modules. It supports some basic types (INT, float, char), arrays and NaCl descriptors. External data presentation layers such as XDR or Protocol buffers can also be easily placed on a NaCl message or srpc

The implementation of npapi is also based on IMC and supports a subset of common npapi interfaces. Currently, the supported operations include reading, modifying, and calling the attributes and methods of Script objects in the browser, and drawing simple raster images, the createarray method is provided to create arrays and open and use URLs like file descriptors. Subsequent improvements are still under consideration.

In addition:

Google's sandbox effect refers to another completely different concept...

it is said that it is difficult for new websites to rank well in Google, no matter how you optimize the website. In other words, a new website can have a lot of related content and a lot of high-quality links. The website is both search engine friendly and user friendly, and everything is well optimized. However, within a period of time, it is difficult to get a good ranking in Google.