Encrypted storage

[exquo]

Currently signal-cli stores its data (contacts info, received attachments, etc) unencrypted in ~/.local/share/signal-cli/ (or /var/lib/signal-cli/ when run as a system daemon). Should this data be encrypted? Under which conditions does that increase security? How can it be implemented?

A full disk encryption prevents unauthorized access at rest when an attacker has a physical access to the disk. However, it does not protect from e.g. compromised programs running in user-space. By default linux programs have access to all the files of a user running it. So an exploit could send all of it to the attacker's server.

One could use something like tomb that would temporarily decrypt the storage while signal-cli is used. However, "temporary" can be a long time, especially if signal-cli daemon is run in the background.

A more secure approach would require modifying signal-cli's code to never store decrypted data on the disk. Maybe some sort of transparent encryption (fscrypt?) could be used. The challenge is to limit access to the decrypted data to the signal-cli process alone.

Then there are some "compartmentalizing" solutions, e.g. running the signal-cli process under a separate linux user, a la android's apps separation. It does not actually require encryption, but does protect from a threat model described above. (Note that it would be pointless to try to protect from a rogue program with a root access, since it can, among other things, be running a keylogger.) Or SELinux / AppArmor? More involved solutions using containers, virtual machines, etc are, of course, also possible.

Would be curious to know what other people think about this.

[orazioedoardo]

Then there are some "compartmentalizing" solutions, e.g. running the signal-cli process under a separate linux user, a la android's apps separation. It does not actually require encryption, but does protect from a threat model described above.

You can run the JSON RPC service sandboxed using the sample systemd unit and socket unit. This protects other software from signal-cli, though, not the other way around, unless you run all software like this or inside restricted docker containers.

[exquo]

Right. When used as a system service, the signal-cli process runs as a separate user. And, thanks to #852, it should be pretty limited in what it can do. The /var/lib/signal-cli, however, is readable by regular users, which gives a compromised program running in userspace access to the data.

Such compromised programs can also run the signal-cli executable itself or send commands to the daemon. But that is less probable: a non-targeted attack is more likely to just scoop up the data from the disk (typically, they go for .ssh, .gnupg and such).

Running signal-cli (and all of the programs that use it) as a dedicated user (rather than a system service available to other users) should help in the above scenario. This solution might not acceptable for everyone though, as it's less convenient than running signal-cli under their regular user.

Incidentally, using docker has the same issue if a persistent non-encrypted storage is used (i.e. signal-cli's data is preserved between docker restarts).

[orazioedoardo]

The linked units do most of what you are saying:

1. Runs the daemon as separate user, signal-cli.
2. Sets umask such that other users can’t read files in the data folder.
3. Creates the unix socket only writable by root and users in the signal-cli group.

Other users can still run signal-cli, but with a different, independent, configuration. By the way, what problem other than physical access would encryption solve?

[exquo]

I stand corrected: when signal-cli is run as a system service (either DBus or socket), only the signal-cli user has access to signal-cli data (contacts, received attachments, etc). While /var/lib/signal-cli is readable by all users (mode 755), the signal-cli dirs /var/lib/signal-cli/{data,attachments,avatars,..} are only readable by the signal-cli user (mode 700).

That should take care of the threat model I had in mind: a malicious program running as the regular user accessing files in signal-cli data dirs. Together with a disk encryption it makes for a pretty secure way of handling signal data.