Page MenuHomePhabricator

Make Onion Key backup more accessible
Closed, ResolvedPublic

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 http://backdrift.org/recursive-inotify-scripting-with-lsyncd.

*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.

Details

Impact
Normal

Event Timeline

HulaHoop updated the task description. (Show Details)Jun 15 2015, 12:57 AM
HulaHoop set Impact to Normal.
HulaHoop added a subscriber: HulaHoop.
HulaHoop created this task.
HulaHoop claimed this task.
HulaHoop raised the priority of this task from to Needs Triage.

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.

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.

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.

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)?

Notes to self:

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

set -x

kdesudo dolphin /var/lib/tor
HulaHoop renamed this task from Automatic Onion Key Backup to Make Onion Key backup more accessible.Jun 16 2015, 7:17 PM

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.

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?

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

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

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

Patrick edited projects, added Whonix 12; removed Whonix-Host.Jun 23 2015, 12:01 AM
Patrick triaged this task as Normal priority.

All merged.

chmod +x usr/lib/gateway-shortcuts/tordata:
https://github.com/Whonix/anon-gw-anonymizer-config/commit/bac763816f16cc5fd9dbd0c7ab261db8f351289a

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.

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.

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 changed the task status from Open to Review.Jul 29 2015, 5:37 PM

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

Patrick closed this task as Resolved.Nov 19 2015, 8:49 PM