Make Onion Key backup more accessible

[phabricator-migrator]

Information

ID: 352
PHID: PHID-TASK-rdy2icthhbc5fadlrg2r
Author: HulaHoop
Status at Migration Time: resolved
Priority at Migration Time: Normal

Description

This ticket is a sub-task of https://phabricator.whonix.org/T21. This is for the design and implementation of an automatic backup mechanism for Onion Site keys.

Design Points:

*lsyncd configured like the example section “Inotify Backup - Backup Files When Changed” from Recursive Inotify Scripting With Lsyncd - Backdrift Backdrift.

*a systemd service that runs lsyncd command: lsyncd -pidfile /var/run/backup.lsyncd /etc/lsyncd.d/backup.lsyncd

The backup target will be the user home folder. The user makes a decision when and if the keys should go into the shared folder. For example they will want to do this when only the gateway is permitted access to the shared folder for security.

Comments

---

HulaHoop

2015-06-15 20:08:56 UTC

This works on system startup

[Unit]
Description=Automatically syncs Onion Site keys to the home folder
ConditionPathExists=/var/lib/tor

[Service]
Type=oneshot
ExecStart=/usr/bin/rsync -a --chown=user:user -br /var/lib/tor /home/user

[Install]
WantedBy=multi-user.target

For presentation I tried adding: /bin/rm -f /home/user/tor/* as an ExecStartPost but it doesn’t work.

It would be nice to have this service as a daemon running constantly so it would create a backup during a session instead of needing a restart but I don’t know how.

---

Patrick

2015-06-16 13:38:40 UTC

What’s the purpose of this? Users being able to more easily find their onion keys since FHS is not really user intuitive?

Let’s suppose on shutdown /var/lib/tor gets damaged. After reboot the backup in home would be overridden. No advantage by this auto backup. It would require a versioned backup where old files aren’t automatically deleted.

Possible confusion: On restoration, users won’t be trying to copy their keys into home and then wonder why those will not be used by Tor?

What I personally find useful in such cases is putting such folders under version control using git init. I haven’t researched automation yet. Any (atomic) damages could be detected and rolled back to a working version. However, for end users the usability of git doesn’t suffice. Not an end user tool.

---

HulaHoop

2015-06-16 16:43:58 UTC

What’s the purpose of this? Users being able to more easily find their onion keys since FHS is not really user intuitive?

I guess. Now that you bring it up I’m not convinced that it makes sense anymore. Good points you bring up on limitations too.

We shouldn’t try to invent GUIs and usability hacks all over the place when everything is one or two commands away. However a very simple solution that makes the tor folder accessible from the desktop would make sense and not be a “usability hack”.

Something like the desktop shortcut “Tor user config” on gw, that opens /var/lib/tor via kdesudo dolphin is a good idea. A user opens the folder up and copies what ever they need into a shared folder.

---

Patrick

2015-06-16 16:50:14 UTC

Something like the desktop shortcut “Tor user config” on gw, that opens /var/lib/tor via kdesudo dolphin is a good idea. A user opens the folder up and copies what ever they need into a shared folder.

That makes sense. New ticket?

Problem is once you open dolphin via kdesudo and copy some files, those will be owned by root. So copied as root to shared folders. I guess users would wonder why they cannot delete their files once access from the host (owned by root, not user account)?

---

HulaHoop

2015-06-16 16:57:37 UTC

Notes to self:

anon-gw-anonymizer-config
/usr/lib/gateway-shortcuts/tordata

set -x

kdesudo dolphin /var/lib/tor

---

HulaHoop

2015-06-16 22:15:58 UTC

That makes sense. New ticket?

I didn’t see your reply before I posted. I think I’ll just keep this ticket and change its title to reflect the new direction its taken.

Problem is once you open dolphin via kdesudo and copy some files, those will be owned by root. So copied as root to shared folders. I guess users would wonder why they cannot delete their files once access from the host (owned by root, not user account)?

Shouldn’t matter because with KVM shared folders, any file moved in there hs its permissions/owner changed to qemu no matter what and will need to have chown run on the host to be able to interact with them there.

So nothing will change from the POV of usability for whats happening now.

---

Patrick

2015-06-16 23:24:47 UTC

HulaHoop (HulaHoop):

HulaHoop added a comment.

That makes sense. New ticket?

I didn’t see your reply before I posted. I think I’ll just keep this ticket and change its title to reflect the new direction its taken.

Ok.

Problem is once you open dolphin via kdesudo and copy some files, those will be owned by root. So copied as root to shared folders. I guess users would wonder why they cannot delete their files once access from the host (owned by root, not user account)?

Shouldn’t matter because with KVM shared folders, any file moved in there hs its permissions/owner changed to qemu no matter what and will need to have chown run on the host to be able to interact with them there.

So nothing will change from the POV of usability for whats happening now.

Alright.

Any chance to make this also work for VBox?

---

HulaHoop

2015-06-17 00:13:01 UTC

It would make sense that VBox would need recursive chown on the host as well (if it didn’t already). Can you test it?

---

Patrick

2015-06-17 00:25:08 UTC

Yes. Also a non-issue for VBox. Gets permission of the user even when
using sudo touch /mnt/shared/test-file. Great.

---

HulaHoop

2015-06-18 01:00:38 UTC

Is anything else besides https://phabricator.whonix.org/T352#5550 needed to create the shortcut?

---

Patrick

2015-06-20 19:17:14 UTC

Yes, the .desktop file.
Folder: anon-gw-anonymizer-config/usr/share/applications at master · Whonix/anon-gw-anonymizer-config · GitHub

---

HulaHoop

2015-06-21 17:26:14 UTC

Please review pulls and feel free to close ticket when merged:

add onion-grater-list by nyxnor · Pull Request #2 · Whonix/anon-gw-anonymizer-config · GitHub

Error Conflicts with diverts-etc++defaults++tor · Issue #1 · Whonix/anon-gw-anonymizer-config · GitHub

---

Patrick

2015-06-22 16:17:29 UTC

For a shortcut, modification of https://github.com/Whonix/whonix-gw-desktop-shortcuts/blob/master/debian/whonix-gw-desktop-shortcuts.postinst#L24 is required.

---

HulaHoop

2015-06-22 18:10:11 UTC

Done.

https://github.com/Whonix/whonix-gw-desktop-shortcuts/pull/1

---

Patrick

2015-07-10 14:23:00 UTC

All merged.

chmod +x usr/lib/gateway-shortcuts/tordata:
chmod +x usr/lib/gateway-shortcuts/tordata · Whonix/anon-gw-anonymizer-config@bac7638 · GitHub

What happens in case the folder does not exist? I.e. at first boot without having Tor enabled at this point? Most likely won’t work then as is currently.

---

HulaHoop

2015-07-11 00:49:32 UTC

I’m not sure. Its not a problem f it doesn’t fail hard with a confusing error message. The time between enabling Tor and using the folder will be small enough that it won’t inconvenience anyone.

---

Patrick

2015-07-11 00:59:09 UTC

It would be confusing if users wanted to restore their old folder before they start. But nevermind. It’s a non-issue. The postinst will have /var/lib/tor created already.

---

Patrick

2015-07-29 15:37:28 UTC

Anything left to do here? Besides testing as soon as a new test image is released?

---

HulaHoop

2015-07-29 18:52:02 UTC

Nope.