When opening a tomb file with "ro" passed through the -o option, the
writability check in is-valid-tomb() is skipped. This allows tomb files
to be opened without write permission.
test-open-read-only() now succeeds.
Due to the hidden-recipient, GPG will try all the available keys. User
can speed up this process providing the recipent using the -r
option. Therefore, 'tomb open' optionaly support the -r option.
tomb doesn't need lsof for anything else, and can work regulary without it.
So make it an optional feature, which allows to slam a tomb if lsof is installed
Updates additionally the man page and generates a new pdf from it
The -r option always requires an arguments. However GPG does not need
any recipient when decrypting a key. In order to be able to open a tomb
without writing (the long) recipient, the user can use the -f option to
short-cut the valid recipient checking. A dummy recipient is still required.
Sharing feature is a very sensitive action, the user needs to trust the
GPG public key it is going to share its tomb. This is why this feature
needs to be explicitly activated using in more the flag --shared
on the key encryption commands.
A tomb key can be encrypted with more than one recipient. Therefore, a
tomb can be shared between different user. The multiple recipients are
given using the -r (or/and -R) option and must be separated by ','.
Multiple recipients can be given for the commands: forge, setket and passwd
Decryption/Encryption works without these improvment, however, there
are needed in order to have clean key (without empty line).
Moreover, tests showed not doing cause troubles when changing the GPG key
used to encrypt a tomb key.
The tomb policy is to use the same password to encrypt
the key and to bury it. However, steganography cannot be
done with GPG key. Therefore, we check the user can
decrypt the tomb with its GPG key and we ask for a
steganography password. Having different method is a
technical requirement and should enhance security.
Apparantly fuser didn't report back, if the tomb was mounted in a subdir of /run (whereas /run itself is often a tmpfs mount).
With no list of process ids those couldn't be killed, so slamming the tomb failed.
lsof is capable to report back the sought information.
Fixes#220
Additionally fixing the debug output, where a hardcoded mountpoint was used
Addresses issue #238: as 512 bit key length triggers use of AES256.
Apparently so far tombs used AES128 due to key length 256.
Change passes all tests and has no regression implications.
The chmod/chown launched on the mounted volume is not really effective
for security, plus the UID is not correctly guessed when tomb is
launched using sudo. It is now up to the user to correctly set
ownership and permission on mounted volumes. There is also one less
check on the ownership of the tomb file which was failing with a
warning in the same case.
this new parser works with all ZSh versions and brings overall
improvement by eliminating the invocation of exernal binary `grep`
over the secret data.
refactored list_tomb_binds to parse /proc/mounts
also works around Debian's infamous \040(deleted) bug
also minor fix in regex umount for more recent zsh
closes bug #222
if resize is launched at same size, will run partition resize
helps continuing if i.e: pinentry expired waiting for password
after a long resize while operator is away: jurt rerun resize command
The fix is due to the new naming scheme without .tomb extension recently
introduced for mountpoints. While testing this a problem arised with
swish-e related to compression of indexes, to be addressed.
two bugs were left behind by the last refactoring, one about
consistency of the mountpoint naming (now using $TOMBNAME everywhere,
without the added .tomb extension as per #180), the other about a
missing _sudo to prefix rmdir commands.
Test suite has been updated accordingly.
This fix introduces a mandatory condition for the next update: all
tombs must be closed when upgrading the tomb script, else it will not
be able to correctly close them.
Previously, the code was relying on `file` and `dmsetup` to detect
encrypted swaps, but it was missing plain swaps on encrypted
volumes. Using `lsblk` adds this detection and simplifies the test.
Thanks @fsLeg for reporting the issue, and @boyska for fixing it.
Commit 5dbcabdf26 removed the `chown` call
in `_tmp_create()` but not the associated error message. This commit
removes that error message since it is just dead code.
This commit refactors the handling of password input by eliminating
all intermediary programs and relying only on ZSh, hence improving
overall security against rootkits and such.
Also the way sudo is used is now greatly simplified and there is no
privilege escalation at boot: sudo is executed inside Tomb by being
prefixed in front of those programs needing it.
All tests passed.
swish-e now creates a .swishrc config file inside the tomb so that
users can tweak its configuration by hand.
whoami() is also cleaned up, pending a fix for slackware usage.
A tempfile was often used by Tomb in order to parse the stderr output of
gpg and detect if the password is correct or not. The tempfile was not
holding any secret information (see #162) yet this is an improvement for
Tomb's deniability since there is now much less going on in the temp
firectory.
Added the --tmp flag for manual selection of the temporary directory, whose security should really be up to sysadmins when configuring operating systems. Default is ZSh TMPPREFIX usually set to /tmp/zsh which, if not existing, will be created as world writable with a sticky bit.
This commit also includes a cleanup of commandline options and a fix to swap check.
Now there is no more writing of cleartext secrets in any tempfile,
the last case was in setkey and is now eliminated. Tempfile creation
is cleaner. Related to issue #162
Using the 'cleartext' name for a key will read it from stdin and
expect it to be unencrypted. This is an unsafe mode of operation,
but useful i.e. to open remote tombs by piping the key over ssh,
or using a different software than Tomb to de/crypt keys.
This commit also renames the flag --unsecure-dev-mode into --unsafe
and includes a minor fix to the last opened date shown on open.
Addressing issue #161
after fixing issue #154 with echo here we revert to using print with
options -R -n which sort the same effect. Print is preferred since it
executes the built-in command without any possible ambiguity. We don't
want to expose secrets to an external executable in case of a simple
attack that would change the env PATH to use a rootkitted echo.
Switched to use echo with -E flag to disable escapes in keys: escape
strings were discarded cryptsetup tomb operations when they were present
in the decoded key random passphrase. Issue #154
The solution adopted here includes wrapping all cryptsetup operations to
unify the behaviour adopted.
Worth noting that this problem possibly breaks all tombs and keys
created using the unstable Tomb from git development in the past 2
months. Regression tests with previous stable releases are OK.
