mirror of
https://github.com/xpipe-io/xpipe.git
synced 2024-11-25 00:50:31 +00:00
Add security policy
This commit is contained in:
parent
d9a18daed5
commit
ecef6c15af
1 changed files with 83 additions and 0 deletions
83
SECURITY.md
Normal file
83
SECURITY.md
Normal file
|
@ -0,0 +1,83 @@
|
|||
# Security
|
||||
|
||||
This document summarizes the approach of X-Pipe when it comes to the security of your sensitive information.
|
||||
If any of your questions are left unanswered by this document, feel free to file an
|
||||
issue report so your question can be answered individually and can also potentially be included in this document.
|
||||
|
||||
## Goals
|
||||
|
||||
The main goals of the security approach of X-Pipe can be summarized as follows:
|
||||
- Any sensitive information should be kept as secure as possible exclusively on your local machine,
|
||||
both while X-Pipe is running and also not running
|
||||
- When sensitive information is required on another remote system that is connected through X-Pipe, that information should
|
||||
remain there as briefly and securely as possible
|
||||
- Any infected remote system should be isolated enough such that any infection can't spread through X-Pipe
|
||||
|
||||
## Assumptions
|
||||
|
||||
The general assumption is that the system on which X-Pipe runs on is not infected.
|
||||
This refers to your local system on which you installed X-Pipe, not any remote systems that you then connect too.
|
||||
If your local system is infected, then there is no
|
||||
technical way of preventing malicious programs to also infect X-Pipe and the connected systems as well.
|
||||
|
||||
Any underlying remote connection command-line tool should be secure.
|
||||
If for example your SSH connection is susceptible to MITM attacks, or
|
||||
vulnerable in any other way, there is no way for X-Pipe to keep the sensitive information secure.
|
||||
As X-Pipe completely outsources any connection handling to your command-line tools,
|
||||
it is your responsibility to keep them up to date with security patches and more.
|
||||
X-Pipe can only be as secure as your underlying command-line tools itself.
|
||||
|
||||
## Storage of sensitive information
|
||||
|
||||
All sensitive information is encrypted when it is saved to disk on your local machine using AES
|
||||
with either:
|
||||
- A custom master key that can be set by you (This option is only as secure as the password you choose)
|
||||
- A somewhat dynamically generated key (This option can be reverse
|
||||
engineered though, there is no way of perfectly securing your data without any custom user input)
|
||||
|
||||
## Passing of sensitive information
|
||||
|
||||
When any kind of login information is required by a command-line tool, it has to be passed somehow to it.
|
||||
If this commandline tool runs on your local system, the data does not leave your local system.
|
||||
If login information is required on a remote system, then that data is transferred to that remote system.
|
||||
|
||||
In case a tool accepts password input via stdin, this process is relatively straightforward.
|
||||
Then the passed sensitive information does not show up in any history or file system.
|
||||
|
||||
When a program only accepts password input via an environment variable or an askpass program,
|
||||
a self deleting password supplier script file is generated by X-Pipe.
|
||||
This script contains the encrypted password and will supply
|
||||
to password to the target program exactly once and immediately deletes itself.
|
||||
This behavior ensures that there is no leftover password script after an operation is performed.
|
||||
As a secondary measure, for cases in which the calling program crashes
|
||||
and is not able to execute and therefore delete the password script,
|
||||
the generated script directory is also frequently cleaned.
|
||||
|
||||
As a result, no sensitive information of yours should show
|
||||
up in any kind of shell history or on any file system in plaintext and also in general.
|
||||
|
||||
## The purpose of shell scripts
|
||||
|
||||
Whenever you open any remote connection in a terminal from X-Pipe, you will notice that your terminal shows
|
||||
the name of a script located in your temp directory in the title bar to indicate that you're currently executing it.
|
||||
The naming scheme of these scripts is usually something like `xpipe/exec-<id>.(bat|sh|ps1)`
|
||||
This is intended as these scripts contain all commands that are required
|
||||
to realize the functionality of connecting and initializing the shell environment.
|
||||
These scripts do not contain any sensitive information,
|
||||
you are free to inspect them yourselves in the temp directory.
|
||||
|
||||
## Isolation of remote systems
|
||||
|
||||
When you add remote system as a host, it is implicitly assumed that you trust this system.
|
||||
Any required login information is sent to and handled on that remote host when required,
|
||||
so it would be possible for malicious programs to obtain any information send to that host.
|
||||
|
||||
It should however not be possible for any malicious program on the remote host to obtain
|
||||
other information stored by X-Pipe that is not explicitly sent to that host.
|
||||
During development, a lot of focus lies on preventing all
|
||||
sorts of attacks like injection attacks from the remote host
|
||||
|
||||
## Reporting a security vulnerability
|
||||
|
||||
If you believe that there is a security vulnerability in X-Pipe,
|
||||
you can make use of the [private security report feature](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing/privately-reporting-a-security-vulnerability) of GitHub.
|
Loading…
Reference in a new issue