What is linux gate

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

Benign remote code execution

License

gate-computer/gate

This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Sign In Required

Please sign in to use Codespaces.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

Run untrusted code from anonymous sources. Instead of sending messages composed of passive data, send programs which can react to their environment. Migrate or duplicate running applications across hosts and computer architectures. See Introduction to Gate.

WebAssembly is the interchange format of the user programs. However, the APIs are different from the browsers’ usual WebAssembly environments. See low-level C API or the higher-level Rust crate for details.

The sandboxing and containerization features of the Linux kernel provide layers of security in addition to WebAssembly. See Security for details.

Gate services are akin to syscalls, but they work differently. New services can be added easily, and available services are discovered at run time. See Service implementation for details.

Gate appears as Go packages and programs. The execution mechanism is implemented in C++ and assembly. It is highly Linux-dependent. x86-64 and ARM64 are supported.

• wag: The WebAssembly compiler (implemented in a separate repository).
• gate/runtime: Core functionality. Interface to the execution mechanism.
• gate/image: Low-level executable building and instance management.
• gate/build: High-level executable building and snapshot restoration.
• gate/server/web: HTTP server component which executes your code on purpose. It has a RESTful API, but some actions can be invoked also via websocket.
• gate/service: Service implementation support and built-in services.

• gate: Command-line client for local daemon and remote servers. Uses SSH keys (Ed25519) for authentication.
• gate-daemon: D-Bus daemon for running and managing instances and wasm modules locally.
• gate-server: Standalone web server which can serve the public or require authentication.
• gate-runtime: For optionally preconfiguring the execution environment for daemon/server, e.g. as a system service.

The available services are determined by what is built into the gate-daemon and gate-server programs. The versions provided by this Go module include only the services implemented in this repository. See extension about bundling additional services.

While code is data, most of the time data cannot be treated as code for safety reasons. Change that at the Internet level. Data encapsulated in code can describe and transform itself.

Application portability. Migrate processes between mobile devices and servers when circumstances change: user presence, resource availability or demand, continuity etc.

Overhead needs to be low enough so that the system can be practical. Low startup latency for request processing. Low memory overhead for high density of continually running programs.

• Linux x86-64 host support
• Android host support (#33)
• Support for WebAssembly version 1
• Planned security measures have been implemented
• HTTP server for running programs
• Client can communicate with the program it runs on the server
• Speculative execution security issue mitigations
• Pluggable authentication
• Load programs from IPFS
• Reconnect to program instance
• Snapshot
• Restore
• Mechanism for implementing external services in language agnostic way (gRPC)
• Full ARM64 host support
• Programs can discover and communicate with their peers on a server (#23)
• Milestone 1
• Clone programs locally or remotely, with or without snapshotting (#9)
• Milestone 2
• Useful resource control policies need more thought (cgroup configuration etc.)
• More services
• Stable APIs
• Additional security measures (#24, #25)
• Non-Linux host support

• Low-level C API
• Rust support
• Go support
• Approach for splitting WebAssembly app between browser (UI) and server (state)

Requirements and build instructions

• Programs other than gate require Linux 5.3. gate‘s remote access features should work on any operating system, but are routinely tested only on Linux.
• D-Bus is used for communication between gate and gate-daemon, requiring D-Bus user service (dbus-user-session). gate doesn’t require D-Bus when accessing a remote server.
• Programs other than gate may need external tools depending on their configuration and capabilities.

There are two approaches to building Gate: the normal Go way, or via the make.go build system.

The Gate programs can be built normally using the Go toolchain:

go install gate.computer/cmd/gate@latest go install gate.computer/cmd/gate-daemon@latest go install gate.computer/cmd/gate-runtime@latest go install gate.computer/cmd/gate-server@latest 

Gate runtime needs to execute some separately built binaries. To make the built Go programs self-contained, pre-built binaries are bundled into them by default. The pre-built binary files are under version control, and can be rebuilt using go generate . To disable bundling of pre-built binaries, specify -tags=gateexecdir for the Go build command, and use make.go to build and install them separately.

Build everything using make.go

• go run make.go lib builds components implemented with C++ and assembly.
• go run make.go bin builds Go programs without bundling non-Go components.
• go run make.go builds all of the above and more.
• go run make.go check runs tests.
• go run make.go -h shows all targets and options.

The build system builds a standalone installer which can be invoked as root:

Источник

What are ld-linux.so.2 and linux-gate.so.1?

Can you explain the output and the reason linux-gate.so.1 and ld-linux.so.2 show differently than other entries? What are their roles?

1 Answer 1

I hope that you’re not asking about the main entries, which are stating that for the requested library libm.so.6 it was found in the file /lib/libm.so.6 , for example, but are asking about the two outliers.

Why are they displayed differently? for linux-gate.so.1 it’s because it’s not actually a file on-disk — it’s exposed by the kernel as the mechanism for making system calls. For /lib/ld-linux.so.2 it’s because this is the program interpreter that is used for actually running the application.

There’s a pretty good blog entry describing the linux-gate.so, and it explains it pretty well.

For /lib/ld-linux.so.2 , you have to understand a little of what happens when you launch an ELF binary. The short answer is that the kernel handler for these types of binaries uses this file for the purposes of launching the application.

The main purpose of this program is to map the binary into memory, load any referenced libraries in the program (e.g. the libm.so.6 previously mentioned), and then hand off control to the starting address of the binary being executed.

This program is defined as part of the structure of the ELF file, in the INTERP section of the program header. For 32bit linux binaries, this is the typical name of the 32bit interpreter. For 64bit binaries, you’ll find it is typically called ld-linux-x86_64.so.2 (for 64bit x86 platforms).

You can determine this information yourself using readelf -l , and the INTERP section:

INTERP 0x0000000000000238 0x0000000000400238 0x0000000000400238 0x000000000000001c 0x000000000000001c R 1 [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] 

Источник

Jake Shadle Jake-Shadle

Credit to Johan Petersson 2005-08-14, original was located at https://www.trilithium.com/johan/2005/08/linux-gate/ but is now defunct (and broken in Wayback Machine).

When you use the ldd utility on a reasonably recent Linux system you’ll frequently see a reference to an ethereal entity known as linux-gate.so.1:

Example dockerfile for cross compilation of `x86_64-pc-windows-msvc` Rust binaries in a Linux container

This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters

# We’ll just use the official Rust image rather than build our own from scratch

FROM docker.io/library/rust:1.54.0-slim-bullseye

ENV KEYRINGS /usr/local/share/keyrings

RUN set -eux; \

mkdir -p $KEYRINGS; \

apt-get update && apt-get install -y gpg curl; \

# clang/lld/llvm

curl —fail https://apt.llvm.org/llvm-snapshot.gpg.key | gpg —dearmor > $KEYRINGS/llvm.gpg; \

Источник