storing a password file & encrypted zfs

Alain De Vos

Alain De Vos

I have some private data, a password file.
How i solved this.
Created an encrypted zfs.
Code: 
zfs destroy ZT2/encrypted
zfs create -o encryption=on -o keyformat=passphrase -o keylocation=prompt -o mountpoint=/home/x/encrypted ZT2/encrypted

To mount i use
Code: 
zfs load-key ZT2/encrypted
zfs mount ZT2/encrypted

To unmount i use :
Code: 
zfs umount ZT2/encrypted
zfs unload-key -r ZT2/encrypted

What do you think ? Is this a good idea ? Or something better?
 
For a single file I'd simply use gpg. Or better yet, given this is a "password file", put the contents in a password manager.

Encrypted filesystems always have one big flaw: they are only encrypted when the system is down - i.e. as soon as it is mounted, the contents are no longer encrypted. So this will effectively only help if the disk or whole system is stolen. In the latter case it even depends on the configuration (-> automatic mount/decryption doesn't help at all)
 
This is a fine solution.
Another alternative, you could also use geli(8) and create an encrypted file that you mount as a new device in that folder. ZFS is probably better because you have the benefit of snapshots, rollback, streaming etc.

I would suggest looking into sysutils/password-store and using that instead of a text file. You can put its metadata on the encrypted ZFS dataset, but you can also use a non-encrypted storage because sysutils/password-store automatically encrypts your passwords with your GPG private key and this is (usually) protected by a password. It is a very handy way to store your passwords securely, they are also versioned via git automatically.

What I personally use is sysutils/password-store with GPG and git integrated. When I request a password the first time I get prompted for a password, but all other times not because there is a GPG agent that caches the password and opens the whole store.
 
sky asked the right question. I would phrase the same question the following way: (a) What sort of attack are you worried about: someone steals your disk, someone kidnaps you together with the disk, someone rootkits your server, someone listens to the packets on your ethernet, and so on? (b) Where is the decryption key stored? If it is only in your brain, that's very different from it being on the same disk that has some encrypted data on it. (c) For how long does the data stay decrypted? The narrower you make that opening (in space and time), the more secure the data is.
 
sko said:
For a single file I'd simply use gpg.
Click to expand...

That opens the problem of securely wiping the unencrypted file after you encrypt. That is highly non-trivial on filesystems such as ZFS. Wiping probably works on UFS, but it is not documented to do so.
 
cracauer@ said:
That opens the problem of securely wiping the unencrypted file after you encrypt. That is highly non-trivial on filesystems such as ZFS. Wiping probably works on UFS, but it is not documented to do so.
Click to expand...
For me the unsafe moment is between.
-> zfs load-key ZT2/encrypted

-> zfs unload-key -r ZT2/encrypted
See scripts on top op this thread.

Offcourse if would be better if no key was written to disk. But i don't think that's possible with.
-> zfs create -o encryption=on
 
cracauer@ said:
That opens the problem of securely wiping the unencrypted file after you encrypt. That is highly non-trivial on filesystems such as ZFS. Wiping probably works on UFS, but it is not documented to do so.
Click to expand...
you don't have to store the data in a file after decrypting it; AFAIK password-store only ever decrypts to stdout/clipboard during normal operation. For editing it places the tempfile in its own tmpfs and removes it afterwards.
 
cracauer@ said:
That opens the problem of securely wiping the unencrypted file after you encrypt. That is highly non-trivial on filesystems such as ZFS. Wiping probably works on UFS, but it is not documented to do so.
Click to expand...
One could use gpg to decrypt the file in stdout, so there is nothing to wipe afterwards but the console. You can of course grep the output to show only what's needed.
 
cracauer@ said:
That opens the problem of securely wiping the unencrypted file after you encrypt. That is highly non-trivial on filesystems such as ZFS. Wiping probably works on UFS, but it is not documented to do so.
Click to expand...

Sometimes you really make me feel insecure, since I also use and trust gpg-encrypted files to store sensitive data.
But not facing the reality doesn't solve anything.

After I read about the issue you mentioned I agree that any journaling fs will leave data on the HDD which could be used to reproduce decrypted files.
This includes zfs. ZFS is not journaling, but its techniques to ensure data not to be lost lead to the same issue within this context.

So I came up with three ideas, which I like to read your (anyone, of course) opinions to:

1. Don't encrypt a single file, but a tarball (or xz, zip, whatever.)
Point is, it shall contain additional files (any rubbish will do),
since an attacker needs some clues of the file he or she is scanning the disk for, right?
encrypted foo.bar -> decrypted tempdir/*.rubbish + my_secret.file
Which of course leave traces of the decrypted file, but also others with the same date and origin.

2. Decrypt the file temporarily into /tmp/ which is in RAM using tmpfs.
After the file is encrypted again, saved to disk, and deleted from /tmp/, the according RAM shall be cleared, right?
At the latest, when the machine boots after a shutdown.
Of course this may if any only a solution for single user desktops, not for multiuser 24/7 machines.

3. Add a small non-journaling ufs partition (hdd, not ssd) only for this purpose to your system (what's the minimum size for it, anyway? For ZFS I figured out 64M.)
Use it to temporarily store the decrypted file(s).
After the file was deleted write a file (e.g. dd from /dev/random) the same size the partion has to it to wipe all blocks.
 
You must log in or register to reply here.
Back
Top