On Wed, Sep 14, 2016 at 11:44:02AM +0200, Toralf Förster wrote: > I do run a hardened stable Gentoo Linux server w/ kernel 4.7.3-ahrdened-r1 where I use an ext4fs directory /var/lib/tor in the following way : > > scp ~/.cryptoSalt user@host:/tmp > cat /tmp/.cryptoPass | ssh user@host 'sudo -u tor e4crypt add_key -S $(cat /tmp/.cryptoSalt) /var/lib/tor && sudo /etc/init.d/tor start; rm /tmp/.cryptoSalt' > > Works fine after reboot. > > But after 4 days or so a restart of the service "tor" fails with messages like : > > Sep 14 11:27:10.000 [warn] Could not open "/var/lib/tor/data/keys/secret_id_key": Required key not available > Sep 14 11:27:10.000 [warn] Error reading private key from "/var/lib/tor/data/keys/secret_id_key" > Sep 14 11:27:10.000 [err] Error loading private key. > Sep 14 11:27:10.000 [err] Error initializing keys; exiting > Sep 14 11:27:10.000 [warn] Couldn't open "/var/lib/tor/data/state.tmp" (/var/lib/tor/data/state) for writing: Required key not available > Sep 14 11:27:10.000 [warn] Unable to write state to file "/var/lib/tor/data/state"; will try again later > > No way to get it repaired other than rebooting the machine. What does "keyctl list @s" display? And what hapens if you try to rerun the add_key command? You should see something like this: root@kvm-xfstests:~# echo testing | e4crypt add_key -S s:NSAkey Enter passphrase (echo disabled): Added key with descriptor [d9edfc8381c3561a] root@kvm-xfstests:~# keyctl list @s 2 keys in keyring: 676316311: --alswrv 0 65534 keyring: _uid.0 814379254: --alsw-v 0 0 logon: ext4:d9edfc8381c3561a Note that by default add_key inserts the key into the session keyring, and if other programs are messing with the session keyring, or tor gets restarted with in a different session id, it might not have access to the keys any more. Depending on whether the key was just deleted, or tor doesn't have access to the key, tor could function for a while until the inode gets pushed out of memory, in which case it wouldn't be able to read it back in. Remember that the security model of the file system level encryption is that if the key is present on the system, then Unix permissions is what prevents another user's process from being able to read the file. Put another way, you manage to get a particular inode is in the inode and page cache, we do *not* do a "does the process have access to a keyring which has a key needed to access the file" on every single cache access. #1 it would be way too slow, and #2, the VFS fundamentally assumes a single view of the dentry and page cache across the whole system, and we can't do separate instances of the cache based on user or session id. The flip side of this is that if you don't have your session keyrings set up just right, you can end up with a situation where the file is initially read into cache, and the tor daemon is running in a different session, so while the file is still in the cache, the tor daemon is fine, but if the file ever gets pushed out of cache, the tor daemon doesn't have access to the keys needed to read the file from disk. Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
