Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision | Next revisionBoth sides next revision | ||
mobi_2.0 [31.12.2020 08:50] – [self-made collection of other tools] Pascal Suter | mobi_2.0 [31.12.2020 08:51] – [self-made collection of other tools] Pascal Suter | ||
---|---|---|---|
Line 61: | Line 61: | ||
Unsolved issues of this solution: | Unsolved issues of this solution: | ||
* **file ownership** is retained on all the files, so a file belonging to root on the client will belong to root on the backup server.. this brings some security issues, as for example a privilege escalation could be made possible by backing up a copy of bash belonging to root and with the suid bit set.. once the attacker gets unprivileged user access to the backup server, he could start this shell and become root. So it would be preferrable to change at least file ownership to a dedicated user and limit the possibilities for an attack | * **file ownership** is retained on all the files, so a file belonging to root on the client will belong to root on the backup server.. this brings some security issues, as for example a privilege escalation could be made possible by backing up a copy of bash belonging to root and with the suid bit set.. once the attacker gets unprivileged user access to the backup server, he could start this shell and become root. So it would be preferrable to change at least file ownership to a dedicated user and limit the possibilities for an attack | ||
- | * restoring files and browsing backups needs to be simple. for example it should be possible to either use normal '' | + | |
* backups are encrypted before rsync lays a hand on the file, so '' | * backups are encrypted before rsync lays a hand on the file, so '' | ||
* it would be nice to be able to mount an entire backup, or even all backups at once, via for example sshfs. One could then remount it using gocryptfs on the client to see a decrypted representation. however, this brings another isse: the mount should be read-only, so that a hacked client can't destroy existing backups on the backup server. so either we find a way to create a read-only share using for example NFS (possibly tunnelled over ssh) or we find a way to make them read-only on the backup server already before sharing them through sshfs. | * it would be nice to be able to mount an entire backup, or even all backups at once, via for example sshfs. One could then remount it using gocryptfs on the client to see a decrypted representation. however, this brings another isse: the mount should be read-only, so that a hacked client can't destroy existing backups on the backup server. so either we find a way to create a read-only share using for example NFS (possibly tunnelled over ssh) or we find a way to make them read-only on the backup server already before sharing them through sshfs. |