10lines

Security

10lines runs code other people wrote, against databases other people own, with their passwords. This page says how, what that protects against, and what it does not.

Where scripts run

Every script runs in a sandbox made by Zygo: Linux namespaces of its own, a seccomp filter that allows a list of system calls and nothing else, Landlock rules on the file system, a read-only root, and a cgroup that caps its memory (256M), processes (128) and CPU. A run is stopped at 30 seconds of wall clock, and the next run on the same interpreter starts from a clean slate: it cannot see what the one before left behind.

A sandbox has no network unless its project names the hosts it may call, and then it reaches those hosts and nothing else: an IP address, or a name that resolves to this server's own network, cannot be allowed. A script reads its tables through a listener that answers only a ticket made for that one run, and gets its project's secrets handed to the handler, not put in its environment.

What the sandbox is not

It is not a virtual machine. Sandboxes share the host's kernel, so a flaw in the kernel is a way out of one; a VM-based sandbox such as Firecracker or gVisor puts a second layer there, and this does not. Zygo is young and has not had an independent security audit. Its own threat model says what it defends and how. If your scripts must not share a kernel with anybody else's, it can be licensed to run on a server of your own.

Your databases and secrets

  • A data source's address and password, a script's secrets and a connected Google account are encrypted with AES-256-GCM, with a key kept outside the database, and bound to their project: copied onto another project's row, they do not decrypt.
  • A data source on this server's own network is refused, and a connection without TLS goes to the address that was checked rather than asking DNS twice.
  • Statements you, a script or an assistant send are checked before they run: one at a time, nothing that changes a table's shape, and none of the functions that reach for the server's files or run a statement handed to them as text. On a project's own schema they run as that project's database role, which sees nothing else.

Accounts

  • Signing in, asking for a sign-in link and registering are rate-limited per address and per email.
  • Changing your email or password, or deleting your account, wants a sign-in from the last twenty minutes.
  • An invitation works only for the address it was sent to. API keys and assistant connections are stored as hashes and can be limited to tables, and to reading.
  • What an assistant or an API key changes in a project is recorded — which one, for whom, what, where and how many rows — and every member can read it under the project's Activity for 90 days.
  • Pages are served over HTTPS only, with a content security policy that runs this server's own scripts and nothing else.

Reporting a problem

Write to the operator of this server. Please give them a chance to fix it before you tell anybody else.