dropserver

Github

Dropserver Security Model

Dropserver is designed to give users of applications peace of mind. It should not be worrisome to install something from an unknown and therefore not trustable source.

Furthermore if you run a Dropserver for your friends you should not have to worry about what they install and run on your instance.

To achieve this peace of mind we must recognize the harm that untrusted code can do to a user of that application or to the instance and guard against these threats as best we can.

This is in addition to the “standard” threats that affect all web services.

Standard Threats

As applications accessible to the internet Dropserver Appspaces are subject to the full breadth of known and understood threats.

These are dealt with using well established mitigations:

More generally, Dropserver handles as much of the stuff that can impact security (TLS, cookies, CORS, etc..) as it can. With some time and many eyeballs on the open source code Dropserver ought to be acceptably secure and any application that runs within it will benefit from that security.

Threats Specific to Dropserver

In addition to standard well-known threats Dropserver users may be subject to a number of additional threats because:

A Dropserver might be under attack from the inside. A user may try to run code that will deliberately attack the instance, or an evil application unwittingly installed by a well-meaning user could be trying to break into the system.

Here are some improper things an evil application might try to do:

Mitigations

Dropserver assumes every Application is potentially hostile and anything the application is allowed to do will be used in a hostile manner.

To mitigate the threats a Dropserver application will be unable to do anything except create and manipulate data in a dedicated Appspace data directory. Anything else must be explicitly allowed by the Appspace’s owner.

Here are the specific ways in which Applications are limited:

Implementation

Sandboxing the application code is of course the key to achieving these security goals.

Dropserver currently uses Deno as its application code sandbox to run untrusted code while controlling its interactions with the outside world.

Deno is a “Secure Runtime for JavaScript and Typescript”. Unlike node which allows JS scripts access to a very large swath of calls to the underlying operating system, Deno stands in the way of each and every call to the OS. A Deno user can run untrusted code while limiting what that code can do.

In addition to Deno, Dropserver leverages the underlying operating system’s process monitoring and control system (“cgroups” in Linux) to restrict computing and storage resources (roadmap feature).

Finally it is likely that in real-world use the sandbox is wrapped in another layer of security, likely a virtual machine such as Firecracker to limit the damage of a zero-day exploit. (roadmap feature)

Regardless of how the code is sandboxed, the running application will be restricted in the following ways:

Filesystem Access and Protection

For each Appspace file system access is strictly restricted to a few directories: read-only access to the application files and some metadata files, and read-write access to a dedicated data directory. No further filesystem permissions can be granted.

An Appspace can not gain access to other Appspace data directories. An Appspace can only communicate with another Appspace via an http API, as any user would.

While an Application can technically destroy its own data, the consequences of this are limited. Each Appspace’s data directory is regularly backed up and stored in a directory that the application can not access.

Outgoing Network Connections

Appspaces must be granted the right to make network requests from the server. The calls are only allowed if the destination matches a whitelist.

At Appspace creation time the Application suggests a list of urls to whitelist, which the user can examine and alter. Additions to the whitelist at runtime are possible and require user approval (roadmap feature).

Dropserver also attempts to protect users against unwanted outgoing network connections from the browser side. It does so by adding restrictive headers to HTTP responses (in particular a very strict CSP and no CORS). Most modern browsers respect these headers.

Network Listeners

Applications are unable to create any kind of network listener. By the same token, it prevents applications from probing for open and used ports on the host.

Dropserver is the server that listens for incoming network requests. These are then forwarded to the right application as needed.

Computing resources

Each Appspace runs its own Deno Process, which is attached to a cgroup that measures and limits its resource usage. This is a roadmap feature.

Threats Mitigated

Let’s look at our list of basic threats and see how the mitigations neutralize them:

Data exfiltration

Data destruction

Unwanted tracking

Abuse of computing resources

Serving as relay to attack other servers

Status of Implementation

Only some of the ideas outlined here are implemented, and in many cases could be implemented better. It’s mostly a matter of developer time, and eyeballs.