summaryrefslogtreecommitdiffstats
path: root/wiki/src/blueprint/tails_server.mdwn
blob: 3c8034fe17f18b0e33dd0f7870ac2ef7d10972c5 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
[[!meta title="Tails Server"]]

[[!toc levels=3]]

# Vision #

Tails Server should provide a user-friendly way to start onion services that facilitate group collaboration, communication, and data sharing.

Such services are immensely helpful for working together in groups over distance. Usually they are hosted centrally by a third party. This comes with several perils: Users have to trust that the service provider protects their information and does not use it for other purposes or disclose it, and the provider poses as a single point of attack for adversaries. In contrast, a self-hosted onion service comes with several advantages:

* It automatically provides strong encryption between the clients and the server
* It provides server authentication and optionally also client authentication
* It provides anonymity for both the clients and the server
* It's decentralized, reducing the impact fo the compromise of a single system
* It works behind NATs and firewalls
* It limits attack surface

Tails Server should be usable via both a graphical user interface (GUI) and a command line interface (CLI). The interfaces would be used from within a running Tails session (in contrast to the design in the [Legacy Blueprint](https://tails.boum.org/blueprint/server_edition/). The CLI solution would make it easy to administrate Tails Server remotely via SSH.
Both interfaces should make it easy for the user to install and configure services, and automatically configure the services for the use in Tails. It should be a generic solution which makes it easy to add many different services.

In addition to service specific options, the user should be able to choose:

* Whether the server's configuration and data and the onion service's keys and address are stored persistently (i.e. being restored after reboot) or not.
* Whether the service is supposed to automatically start after booting Tails.
* Whether it should allow connections from localhost
* Whether it should allow connections from the local area network (LAN).

In order to achieve this vision, the following problems have to be solved:

* Design an extendible and robust format describing the services and how they integrate into Tails.
* Installing the server software.
* Setting up the onion service, reusing an existing onion address and keys, if chosen by the user.
* Persistently storing the data, configuration, and onion service data.
* Integrating into Tails' firewall.
* Presenting the onion address and client credentials to the user in a way that s/he can easily share them with clients.
* Implementing a proper CLI and GUI to configure and activate services.

## List of services which could be nice if integrated in Tails Server ##
Please add to this list!

* Collaborative text editor
  * Gobby
  * Etherpad (requires web server)
* VoIP
  * Mumble
* Web server
  * Nginx
  * lighttpd
* Filesharing (requires web server)
  * Onionshare
  * NextCloud or Owncloud
  * Cozy
* Wiki (requires web server)
  * MediaWiki
  * ikiwiki
  * DokuWiki
  * MoinMoin
* Leaking platform
  * SecureDrop
  * GlobaLeaks
* XMPP
  * Prosody
  * ejabberd
* IRC
  * charybdis
  * ngIRCd
  * IRCD-Hybrid
* SSH

# Design #
Each service is defined by a separate Python module in `/usr/share/tails-server/services/`. Each service's module must contain a subclass of the `TailsService` class, which defines all the attributes and methods required by a service, e.g. to install, configure, start and stop it. If a service needs additional functionality, the subclass can override arbitrary attributes and methods of the `TailsService` base class.

Options which can be changed by the user can be defined as subclasses of `TailsServiceOption`. Default options include for example the `PersistenceOption` and the `AllowLanOption`. To add service specific options, the `TailsService.options` attribute can be overridden.

The Tails Server GUI monitors D-Bus to get notified when one of the services starts or stops. This implies that each service in Tails Server must have a systemd service which can be monitored this way.


# Implementation #
Tails Server is implemented in Python 3. 


# Service Specification #

The following attributes of the `TailsService` class must be overridden by all subclasses:

## Attributes
- name: The name of the service, as used in the CLI. This should be the same as the basename of the executable file.
- description: A short description of the service.
- client_application: The name of the application which can connt to this service
- documentation: A URL pointing to the service's page in the Tails documentation. For example "file:///usr/share/doc/tails/website/doc/tails_server/mumble.en.html".
- packages: A list of packages that need to be installed for this service.
- systemd_service: The name of the service's systemd service. ยน 
- default_target_port: The default value of the service's target port (i.e. the port opened by the service on localhost), which is used if the user does not specify a custom target port.
- icon_name: The name of the icon used for the service in the GUI.


Additionally, the following attributes might be overridden:

- persistent_paths: List of paths of files and directories that should be made persistent via the Persistence option.
- options: List of the service's options.
- systemd_service: The name of the service's systemd service.
- name_in_gui: The name of the service, as displayed in the GUI.
- client_application_in_gui: The name of the application which can connect to this service, as displayed in the GUI.
- default_virtual_port: The default value of the service's virtual port (i.e. the port exposed via the onion service), which is used if the user does not specify a custom virtual port.
- connection_info: A summary of all information necessary to connect to the service
- connection_info_in_gui: The connection as it should be displayed in the GUI


## CLI options

#### info [--details]
Print a mapping of attributes of the service to their current values. With *--details*, additional attributes will be printed.
  
##### Example 1

    $ mumble.py info
    description: A low-latency, high quality voice chat server
    installed: true
    running: true
    address: null
    local-port: 64738
    remote-port: 64738
    persistent-paths:
    - /etc/mumble-server.ini
    options:
      virtual-port: 64738
      server-password: TrR4WgC29nUjNIJ5o2VI
      persistence: false
      autostart: false
      allow-localhost: true
      allow-lan: false
      welcome-message: '"<br />Welcome to this server running <b>Murmur</b>.<br />Enjoy your stay!<br />"'


#### status
Print the values of the service's *enabled*, *installed* and *published* attributes.

#### enable
Enables the service, which involves installing the packages, starting the service, and creating the onion service.

#### disable
Stops the service.

#### get-option OPTION
Prints the value of the provided option.

#### set-option OPTION VALUE
Sets the provided option to the provided value.