-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Hi,
I made the following steps to have /var/lib/tor encrypted under an ext4fs under a stable Gentoo Linux:
at a local system: head -c 16 /dev/random | xxd -p > ~/tmp-salt.txt; echo 0x`cat ~/tmp-salt.txt` > ~/.cryptoSalt; rm ~/tmp-salt.txt picked up a password from: pwgen -s 16 open the remote directory: scp ~/.crypto{Pass,Salt} user@host:home; ssh user@host 'cat ~/.cryptoPass | sudo e4crypt add_key -S $(cat ~/.cryptoSalt) /var/lib/tor; rm ~/.crypto{Pass,Salt}'
debug.log tells me:
... Aug 21 15:09:23.817 [notice] Opening Directory listener on [2a01:4f8:190:514a::2]:80 Aug 21 15:09:23.000 [warn] Your log may contain sensitive information - you're logging more than "notice". Don't log unless it serves an important reason. Overwrite the log afterwards. Aug 21 15:09:23.000 [debug] tor_disable_debugger_attach(): Attemping to disable debugger attachment to Tor for unprivileged users. Aug 21 15:09:23.000 [debug] tor_disable_debugger_attach(): Debugger attachment disabled for unprivileged users. Aug 21 15:09:23.000 [info] tor_lockfile_lock(): Locking "/var/lib/tor/data/lock" Aug 21 15:09:23.000 [warn] Couldn't open "/var/lib/tor/data/lock" for locking: Operation not permitted Aug 21 15:09:23.000 [err] set_options(): Bug: Acting on config options left us in a broken state. Dying. (on Tor 0.2.8.6 )
and indeed :
# ls -alR /var/lib/tor/ /var/lib/tor/: total 12 drwxr-xr-x 3 tor tor 4096 Aug 21 15:09 . drwxr-xr-x 14 root root 4096 Aug 21 03:10 .. drwx------ 2 tor tor 4096 Aug 21 15:09 data - -rw-r--r-- 1 root root 0 Aug 19 14:47 .keep_net-misc_tor-0
/var/lib/tor/data: total 8 drwx------ 2 tor tor 4096 Aug 21 15:09 . drwxr-xr-x 3 tor tor 4096 Aug 21 15:09 ..
Any hints ?
- -- Toralf PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7
Op 21/08/16 om 15:14 schreef Toralf Förster:
Hi,
I made the following steps to have /var/lib/tor encrypted under an ext4fs under a stable Gentoo Linux:
at a local system: head -c 16 /dev/random | xxd -p > ~/tmp-salt.txt; echo 0x`cat ~/tmp-salt.txt` > ~/.cryptoSalt; rm ~/tmp-salt.txt picked up a password from: pwgen -s 16 open the remote directory: scp ~/.crypto{Pass,Salt} user@host:home; ssh user@host 'cat ~/.cryptoPass | sudo e4crypt add_key -S $(cat ~/.cryptoSalt) /var/lib/tor; rm ~/.crypto{Pass,Salt}'
debug.log tells me:
... Aug 21 15:09:23.817 [notice] Opening Directory listener on [2a01:4f8:190:514a::2]:80 Aug 21 15:09:23.000 [warn] Your log may contain sensitive information - you're logging more than "notice". Don't log unless it serves an important reason. Overwrite the log afterwards. Aug 21 15:09:23.000 [debug] tor_disable_debugger_attach(): Attemping to disable debugger attachment to Tor for unprivileged users. Aug 21 15:09:23.000 [debug] tor_disable_debugger_attach(): Debugger attachment disabled for unprivileged users. Aug 21 15:09:23.000 [info] tor_lockfile_lock(): Locking "/var/lib/tor/data/lock" Aug 21 15:09:23.000 [warn] Couldn't open "/var/lib/tor/data/lock" for locking: Operation not permitted Aug 21 15:09:23.000 [err] set_options(): Bug: Acting on config options left us in a broken state. Dying. (on Tor 0.2.8.6 )
and indeed :
# ls -alR /var/lib/tor/ /var/lib/tor/: total 12 drwxr-xr-x 3 tor tor 4096 Aug 21 15:09 . drwxr-xr-x 14 root root 4096 Aug 21 03:10 .. drwx------ 2 tor tor 4096 Aug 21 15:09 data -rw-r--r-- 1 root root 0 Aug 19 14:47 .keep_net-misc_tor-0
/var/lib/tor/data: total 8 drwx------ 2 tor tor 4096 Aug 21 15:09 . drwxr-xr-x 3 tor tor 4096 Aug 21 15:09 ..
Any hints ?
Those permissions look fine. Do you have selinux enabled? Did this work prior to adding encryption, or could that be a red herring? Can you see what it fails on with strace? Is tor actually running as the 'tor' user? Do you have any special security configuration like sandboxing set up?
Tom
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 08/21/2016 03:23 PM, Tom van der Woerdt wrote:
what it fails on with strace? Is tor actually running as the 'tor' user? Do you have any special security configuration like sandboxing set up?
Tom
Well, whilst disabling the SandBox at least gave me the lock file - Tor died immediately after that.
Currently I do blame my Gentoo hardened settigns I do use (although I had have the same features (tmp) at my old server have w/o any problems - but ok, local problem so far ASICT.
- -- Toralf PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 08/21/2016 03:23 PM, Tom van der Woerdt wrote:
Did this work prior to adding encryption, or could that be a red herring?
It was the attempt to encrypt the Tor directory using the ext4 method - - GRSecurity is fine (works since 2 years like a charm). But I mistakenly encrypted it as user "root" - whereas user "tor" was the right one.
I described my steps in [1] under "setup". I'm pretty convinced that this is an easy method to ensure an attacker even with physical access to a server (eg. while changing a defect hard disk) can't achieve the secret key.
[1] https://www.zwiebeltoralf.de/torserver.html - -- Toralf PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7
Happy to hear you resolved the problem :-)
Side-note wrt your setup :
You're storing the keys on the disk, and while they're removed immediately after, that potentially leaves them on the physical storage. Since you're already passing them through ssh, consider just having ssh do the stdin bit :
cat ~/.cryptoPass | ssh user@host "sudo -u tor e4crypt add_key -S $(cat ~/.cryptoSalt) /var/lib/tor"
The salt will end up in the sudo log (/var/log/secure, usually) but the password will never hit the disk. No scp needed, and no files to rm afterwards.
Tom
Op 21/08/16 om 17:44 schreef Toralf Förster:
On 08/21/2016 03:23 PM, Tom van der Woerdt wrote:
Did this work prior to adding encryption, or could that be a red herring?
It was the attempt to encrypt the Tor directory using the ext4 method
- GRSecurity is fine (works since 2 years like a charm).
But I mistakenly encrypted it as user "root" - whereas user "tor" was the right one.
I described my steps in [1] under "setup". I'm pretty convinced that this is an easy method to ensure an attacker even with physical access to a server (eg. while changing a defect hard disk) can't achieve the secret key.
[1] https://www.zwiebeltoralf.de/torserver.html _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 08/21/2016 06:35 PM, Tom van der Woerdt wrote:
Side-note wrt your setup :
You're storing the keys on the disk, and while they're removed immediately after, that potentially leaves them on the physical storage. Since you're already passing them through ssh, consider just having ssh do the stdin bit :
cat ~/.cryptoPass | ssh user@host "sudo -u tor e4crypt add_key -S $(cat ~/.cryptoSalt) /var/lib/tor"
The salt will end up in the sudo log (/var/log/secure, usually) but the password will never hit the disk. No scp needed, and no files to rm afterwards.
Tom
Thx for your hints - I'll test your advice soon.
FWIW I do have Defaults !syslog,!pam_session in /etc/sudoers, therefore sudo commands shouldn't be logged I hope. And I do have /tmp as a tmpfs. And finally "tor" is just a technical user w/o login or so.
- -- Toralf PGP: C4EACDDE 0076E94E, OTR: 420E74C8 30246EE7
On 8/21/16, Toralf Förster toralf.foerster@gmx.de wrote:
I'm pretty convinced that this is an easy method to ensure an attacker even with physical access to a server (eg. while changing a defect hard disk) can't achieve the secret key.
rm the key/salt doesn't wipe the underlying data. Wipe the files or the non swap backed fs, or use a pipe. Some tools and allocators might wipe ram regarding core dump. But still, turn off dumps. Considering... - Adversary can always run a node at their cost - Almost all nodes are linux attack surface, not diverse - You keep copy of node key to help show revocation. - You may not discover you're rooted ... don't lose sleep over it. Happy relaying.
tor-relays@lists.torproject.org
-
grarpamp -
Tom van der Woerdt -
Toralf Förster