Productivity Storm

Sharing files is an important topic in team productivity. All employees need reliable access to required information for successful collaboration. Sandstorm is a security-hardened web app package manager built by a community of volunteers to run open source web applications [1]. Sandstorm's server-side sandboxing lets you isolate documents securely with little to no effect on productivity.

Security Risks in Modern Collaboration

The trend in IT has been toward microservices. Ever since hardware virtualization became widespread, individual services have run separately on different virtual machines. Although hard disk space has always been comparatively affordable, virtualization comes at the price of memory overhead for a full-fledged operating system that gives you access to the physical resources of the computer through paravirtualized drivers.

Modern platforms with container technology, such as Kubernetes, further optimize resource consumption, especially in terms of memory consumption for microservices. Namespaces in the Linux kernel mean that it is no longer necessary to provide an operating system to isolate a piece of software from other running programs or specific files on the filesystem. It is solely a matter of a program's immediate runtime environment (i.e., the shared dynamic system libraries). Calls to the program and library kernel functions can even be processed by a single kernel.

The architecture described here leads to each individual application (e.g., software for cooperative document editing or calendar systems) running in its own container without direct access to the resources of other processes. A database connected on the back end also runs in its own environment, and communication then takes place over a private network that is virtualized in the kernel. Standard tools have been developed for communication over the network.

In terms of IT security, this structure might be unsuitable, no matter how elegant it appears at first glance. Suppose an external user gains access to a company's filesharing service because they need to exchange data with one of the internal employees. A potential attacker who gains access to this user account then controls an authenticated system user. To be able to access further documents, the attacker only needs to find a vulnerability that allows privilege escalation.

The developers of Sandstorm take things a step further: Instead of isolating individual services in individual containers, the software isolates the information itself along with the associated applications. Therefore, every document a user creates in Etherpad, for example, is also assigned its own Etherpad instance and, in an ideal scenario, is the only document in that Etherpad.

From now on, access management to this Etherpad instance is handled by the Sandstorm platform, which can distinguish between read, comment, and read/write permissions. Conceptually, Sandstorm basically demarcates available apps from the documents created with them – the "grains" in tech-speak – to achieve granular access control in the truest sense of the word.

Installing Sandstorm

The hardware requirements for installing Sandstorm are initially low – at least on paper. The developers expect a recent 64-bit Linux with at least 1GB of RAM. The required hard disk size is not specified; Sandstorm itself takes up just north of 2.8GB. In the lab I used, I discovered that a machine with 2GB of RAM and 20GB of storage was fine.

Depending on your choice of installation method, the process can be anything from very simple to pretty complex. You can choose anything from a script, right up to building Sandstorm yourself. I'll take the simplest route here and start the installation directly on the console of an Ubuntu server with the provided script:

curl https://install.sandstorm.io | bash

During the process, you will need to answer prompts about your installation. To test Sandstorm, select a standard installation in the first prompt by pressing Enter. After a short look at the installation steps, you also confirm the next prompt. If you are already running an HTTP server on port 80 or 443 or an email server on port 25, the script will suggest alternative ports, which you can adapt to your local conditions.

The Sandstorm developers have also put some thought into protecting your instance with the Transport Layer Security (TLS) protocol. The sandcats.io domain has free subdomains to help you secure your setup with a certificate from Let's Encrypt. Choose a creative name (some obvious subdomains are already taken) and register with an email address. You do not need to confirm this, but make sure you use an existing address to be able to recover your chosen subdomain later on.

After downloading and installing Sandstorm, you again need to enter an email address at the command line. This time, you need it to register with Let's Encrypt, and you can use a different address than in the previous step. After a short wait for the TLS certificate to install, you will see a link onscreen, which means that the installation completed successfully. Use the link to log in as admin to the instance you just created (i.e., open the link in your browser).

Configuration

You can now start configuring your own instance in the web browser by pressing the matching button. The first step is to select at least one authentication method that you want to offer to your users (Figure 1). The simplest option is passwordless authentication by email. To do this, you need to enter an existing email account, and Sandstorm will then mail a corresponding link whenever you log in. If you use an LDAP server in your organization, you can add its parameters. Alternatively, choose a preconfigured OAuth provider with Google or GitHub or configure your own services with OpenID Connect or Security Assertion Markup Language (SAML). Of course, you can also enable multiple back ends at the same time.

Figure 1: Select login options that are the right fit for your organization.

In the second step for configuring your organization's settings, you need to define a domain for email authentication (i.e., so you can check that it belongs to your organization). You can also restrict the ability to share documents with external guests (Figure 2). A login to your organization would then always be required to access documents. The previously selected option to store all users of an organization in the address book makes it easier for your users to share with each other but also exposes the list of active users to everyone.

Figure 2: In the second step of the installation, you enable authentication with the email domain.

After clicking Save and continue , you are taken to the email setup. Sandstorm sends email to users for various reasons, not only to log in by email. To do this, they need an account on the mail server that allows sending with different domain addresses. Sandstorm sometimes communicates with different sender addresses; for example, each app has its own address for email. The use of a free mail provider is difficult.

Once you have stored a valid email account, the apps selected by the developers will be pre-installed in the next step. Because this has already happened in the background, you can probably click Next here. You can customize the list of apps pre-installed for users later in the Admin panel. At the end of the configuration process, you will need to create an account with admin rights. To do this, enter the email address in the appropriate form, press the button to send a login email, and press Next to complete the configuration.