# IPC threat model

As the client consists of multiple processes, securing their communication was one of the first questions to be
evaluated.

Firstly, all IPC communication is restricted to the local machine by default. External adversaries cannot snoop the
line as the data on pipes and the loopback interface never leave the OS/kernel. It is reasonable to assume that the
operating system will have a baseline security policy/firewall set up and will not allow connections from external
sources be made to these local resources.

By the above statements we are left with the task to investigate the security in the case when an adversary is trying
to or has already compromised some part of the host itself.

## Threats categorized

1. Malicious party gains physical access to machine.
1. Malicious party deceives legitimate user to run harmful software.
1. Malicious party gets (legitimate-or-not) access to machine. (different user account)
1. Malicious party gains administrator privileges on machine.

## Possible impact of exploiting the threats

1. The physical machine is compromised.

    In this case a lot depends on the OS and the configured security measures. The data on the machine can be stolen
    unless it was encrypted and even then it is not guaranteed that a persistent attacker won't break the cipher in
    due time.
    
    If the data can be read from the disk then application configuration files, cached authentication tokens, etc. can
    also be extracted.

    If they specifically wanted to attack the user's Nano they could extract stored session keys and authentication
    tokens from the system and use those to impersonate the victim from another machine. Publishing illicit content in
    their name or just using a Nano licence illegally for their own benefit until the real owner notices and contacts
    support. Many software are similarly vulnerable to key extraction like this.

1. Malicious program is running under the same user privileges.

    If the user running the Nano also happens to run a malicious software from a third party, most of the user's data
    will become compromised regardless of Nano running or not.

    However an attacker might manipulate the Nano by loosening its security policy or adding more private data locations
    as shares. This means they could use it for the attack not by a vulnerability in itself, but by compromising the
    user's account and acting in their name.

1. Malicious program is running under different/separate user privileges.

    In case other users do not have access to the files of the user running Nano, they might want to try and connect to
    the running processes by impersonating one of them. This is particularly easy on loopback sockets because they are
    accessible by anyone on the host.
    
    For example a malicious program may pose as a valid server or gateway process and perform a man-in-the-middle attack
    between the authentic processes.

1. Compromised administrator account.

    If the attacker gains administrator/root privileges then they can already snoop on every data on the computer with
    hardly anything to stop them. Even if there are protections in place to stop them, they will be able to circumvent
    them.

    They could try to MitM attack the communications just like a compromised user would. However no attack vector is
    off limits to them at this point. They can steal the user's account thus their data and access to the Nano instance.

## Threat mitigations

1. For physical security Nano will not implement or impose any restrictions. As most software we also delegate the
implementation of this level of security to be handled by the OS and the administrator of the machine. There are
many different options available on all platforms. Evaluating their options and making these decisions must be done
by the users for their individual needs.

1. Running malicious software by the user cannot be prevented by Nano. It is not in its responsibility to protect
the user's data directly from a software made by a third party. However to mitigate the impact of such an occurrence
extra security options can be implemented to harden the configuration. This would limit the attacker's options to
exploit a running Nano instance.

1. The only interface where other users (and their programs) may try and interact with Nano is the loopback network
interface. To prevent illicit users and applications exchanging messages and requests with Nano processes all socket
communications will require the presentation of a large (impossible to guess) secret value securely shared with all
processes in the running instance. This value is never saved anywhere and changes overtime. 

    Our two main dependencies do not support this level of IPC exclusion. For each start a custom security config
    can be made for Solr with a random basic authentication. Tika server does not have any authentication restriction
    feature. It cannot be used to snoop on the user, but it can be DoS attacked because of the lack of authentication.

1. When the attacker gains administrator privileges there is nothing to be done if they do wish to interfere with
the running processes of Nano.

## Mitigation evaluation

In the case of (1) and (4) we have no obvious cross-platform solution to provide significant added protection.
They are outside the scope of what a user-application can be expected to handle.

In case of (2) we can improve security by making it harder to change existing configurations and running custom
instances. These options will most likely be optional and platform-dependant as well. They will also limit
ease of use.

(3) can be successfully mitigated by authenticating all IPC (socket) communications in a Nano instance so no other
process may ever join in.

## Encrypting localhost communications

This has a significant CPU overhead and does not give meaningful security improvements. When such measure would
yield some benefits, likely even more serious issues are also present which we cannot mitigate at all.

The system must not be compromised such that snooping on the localhost interface is possible. This is how most
programs expect the system to behave. Security research has concluded that inter-process communications inside a
host are not hardened robustly even by password manager applications.
(See Fig 2. on page 6 https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-bui.pdf for short)
It could be argued that this indicates that the general facilities or default solutions for IPC are
lacking in security.

## Conclusion

The security of the user's machine is of the utmost importance, but that is solely up to the owner of the machine.
This is especially true since the system's user-privacy oriented design places the burden of content decryption and
encryption on the user's machine as well.

For enhanced security the user should use advanced security measures supported by their operating system. For example:
MAC policies with SELinux, AppArmor or Firejail policies. These are suitable for securing the Nano processes and also
sand-boxing them in case a vulnerability in them would be exploited.
