---

sandpolis is a virtual estate manager which is a tool for controlling esoterica like your online accounts, cloud servers, and even physical devices.

Virtual estate

Virtual/digital estate is an encompassing term that refers to all digital assets under your control. Some assets may be entirely virtual and mostly controlled by a corporation, like accounts on github.com. Others have a physical component as well, like a Raspberry Pi.

All of these entities are part of your virtual estate and are intricately connected in both obvious and unapparent ways.

As an example, you might have an SSH key or API token on your machine that grants access to repositories (a digital asset) on Github. And suppose your machine also has an authorized key installed that allows access from another machine:

┌──────────┐ SSH Key ┌──────────┐ API Token ┌────────────────┐
│Machine A ┼─────────►Machine B ┼───────────► Github Account │
└──────────┘         └──────────┘           └────────────────┘

This picture represents a simple virtual estate with physical/digital assets that you have a high degree of control over (local machines), and purely digital assets that you have very little control over (an online account).

Sandpolis is about mapping out these relations to provide an overall view of your entire virtual estate. It can do both microscopic management tasks (like: "give me a shell on Machine A") and macroscopic tasks (like: "map out the attack surface of my Github repos").

Who cares about virtual estates anyway?

Whatever you call it, non-physical or digital assets have a significant impact on our "real" lives. Sandpolis places all of those points on a map so you can track them in one place, with the ultimate goal of uncovering who controls what parts of your virtual estate.

Not everyone agrees on how much control we should personally have over our virtual estates. Some people simply don't care - just put it all in the cloud. Others recognize that the "cloud" is just someone else's computer and they're effectively sharing control over their digital assets.

If you're in the first category, then Sandpolis probably doesn't offer much value. For the rest of you, Sandpolis is an invaluable tool that can help shift control of your virtual estate back where it belongs!

How it works

Sandpolis is three applications:

• the agent which is a headless daemon that runs on machines you want to control.
• the client which is a GUI or CLI application that you use to interact with you virtual estate.
• the server which ties everything together and stores persistent state.

If you don't want to run agents, you can also use probes which offer similar functionality, but reuse a common protocol like SSH instead.

Depending on how big your virtual estate is, you can also run multiple servers in the same network arranged into strata: local stratum (LS) servers connect upwards to a global stratum (GS) server. Here's an example network demonstrating all of the above:

┌──────────────┐
│ Client (you) │
└──────┬───────┘
       │ mTLS
┌──────▼──────┐           ┌───────┐
│  GS Server  ◄───────────┤ Agent │
└──────▲──────┘   mTLS    └───────┘
       │ mTLS
┌──────┴──────┐           ┌───────────┐
│  LS Server  ┼───────────► SSH Probe │
└─────────────┘    SSH    └───────────┘

You connect your client to a server, which relays your requests to any agent or probe in the estate. In the above example, your client application can do sandpolis shell <Agent> or sandpolis shell <SSH Probe> to get a shell session on either the agent or the probe.

All connections between instances (clients, servers, agents) are secured with strict mTLS. This means you always need a certificate called a realm certificate to login. Servers can host multiple realms which provide strong isolation for different environments.

Installation

Crates.io

Install from crates.io

cargo install sandpolis

As an added benefit for this installation method, you can customize exactly what features you need. For example, to build with support for remote desktop and nothing else:

cargo install sandpolis --no-default-features --features desktop

As a result, your installation artifacts will be smaller and will be unable to perform any unwanted functionality.

Docker

Install server from DockerHub

# Docker compose
services:
  sandpolis-server:
    image: sandpolis/server
    restart: unless-stopped

Install client from DockerHub

alias sandpolis-client="docker run --rm sandpolis/client"

Try the whole thing at once

The demo image runs a server, an agent and the GUI client together in one container:

docker run --rm -it \
  -e XDG_RUNTIME_DIR \
  -e WAYLAND_DISPLAY \
  -v "$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY":"$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY" \
  --device /dev/dri \
  -v sandpolis-demo:/data \
  sandpolis/demo

Without a compositor handed in, the server and agent still come up and you get a shell aimed at them instead of the GUI:

[sandpolis demo] /data $ sandpolis agents list