dyne/tomb

the Crypto Undertaker

Tomb: The Linux Crypto Undertaker

Minimalistic command line tool based on Linux dm-crypt and LUKS, trusted by hackers since 2007.

You can keep your volumes secure and easily manageable with simple commands.

 $ tomb dig -s 100 secret.tomb
 $ tomb forge secret.tomb.key
 $ tomb lock secret.tomb -k secret.tomb.key

To open it, do

 $ tomb open secret.tomb -k secret.tomb.key

And after you are done

 $ tomb close

Or, if you are in a hurry, kill all processes with open files inside your tomb and close it.

 $ tomb slam

Get started on dyne.org/software/tomb

All information is found on our website.

Use only stable and signed releases in production!

💾 Download from files.dyne.org/tomb

Tomb's development is community-based!

How can you help

Donations are very welcome on dyne.org/donate

Translations are also welcome: see our simple translation guide

Tomb's code is short and readable: don't be afraid to inspect it! If you plan to submit a PR, please remember that this is a minimalist tool, and the code should be short and readable. Also, first, read our small intro to Tomb's coding style.

We have a space for issues open for detailed bug reports. Always include the Tomb version being used when filing a case, please.

There is also a space for discussion of new features, desiderata and whatnot on github.

Licensing

Tomb is Copyright (C) 2007-2024 by the Dyne.org Foundation and maintained by Jaromil. The AUTHORS file contains more information on all the developers involved. The license is GNU Public License v3.

More info on dyne.org/software/tomb

tomb's Issues

slam tomb with no pid

When trying to slam a tomb, tomb tries to kill all processes that keep the tomb open, but no check is performed to ensure that at least one pid is found.

anathema@nrv:/tomb_dev/Tomb/src$ ./tomb slam
[] Slamming tomb mytomb mounted on /media/mytomb.tomb
. Kill all processes busy inside the tomb
umount_tomb:kill:84: not enough arguments
[] Tomb mytomb closed: your bones will rest in peace.
anathema@nrv:/tomb_dev/Tomb/src$

here the code:
if [ $SLAM ]; then
notice "Slamming tomb $tombname mounted on $tombmount"
act "Kill all processes busy inside the tomb"
pidk=lsof -t "$tombmount"
for p in "$pidk"; do
pname=pidof $p
func "killing PID $p of $pname..."
kill -9 $p
done
else
notice "Closing tomb $tombname mounted on $tombmount"
fi

Embedding the key pinentry say: "Open tomb: <keyname>.tomb.key" to set password

In this way is confusing.
Must be something like: "Insert tomb steganography password"

tomb-open need --ignore-swap

the option --ignore-swap need to be added to tomb-open options

notify-send

Would be nice to add notify-send support: if notify-send is installed, tomb can automatically (or by flag) turn on notify over notify-send

Fetch keys from different sources

We don't want to fetch keys just from a plugged usb-storage: also from an ssh shell, or a bluetooth device like a mobile phone.

Initially I've started to implement this inside tomb, but then quickly realized this complicates too much the core code and inserts latencies as well too many configurable aspects beyond its scope.

We can implement these features is an external auxiliary program, something to fetch keys: 'undertaker' might be a good name for it, it would be a specialized application to fetch keys via several different supported protocols....

tomb resize

tomb should make it easy to resize (increment, especially) a tomb; it should ask the user if he want to do this if opening an "almost-full" tomb (see #1)

escaping problem in optparsing branch

the escaping need a more efficent implementation

were founded the problem:

$ tomb open -k 'copia\ di\ tomba.tomb.key' tomba.tomb
[*] Commanded to open tomb di
[!] file not found: di
[!] operation aborted.

fortify safe_dir

Make the temporary safe directory creation stronger: check if /dev/shm is already mounted, if not check if tmpfs is present in the kernel, else give a warning and maybe fail operation. The aim is to use tmpfs as it is possible on the system, possibly keeping all temporary unencrypted data in RAM.

undertaker: scheme "subcommand"

The undertaker is strongly based on the idea of "scheme" (for example, http is the scheme for http://tomb.dyne.org/

When undertaker is requested a scheme that it doesn't know, it should check for the existance of the executable undertaker-$scheme.

This will allow us easier contribution for external software and easier dependency handling for "odd" schemes

Tomb resize

Example here:
https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Resizing_the_loopback_filesystem

yet this works only for ext2/3/4 and things get complicated as we start allowing more filesystem typess... however:

Resizing the loopback filesystem

First we should unmount the encrypted container:

umount /mnt/secret

cryptsetup luksClose secret

losetup -d /dev/loop0 # free the loopdevice.

After this we need to create a second file with the size of the data we want to add:

dd if=/dev/zero of=zeros bs=1M count=1024

You could use /dev/urandom instead of /dev/zero if you're paranoid, but /dev/zero should be faster on older computers. Next we need to add the created file to our container. Be careful to really use TWO ">", or you will override your current container!

cat zeros >> /bigsecret

Now we have to map the container to the loopdevice:

losetup /dev/loop0 /bigsecret

cryptsetup luksOpen /dev/loop0 secret

After this we will resize the encrypted part of the container to the maximum size of the container file:

cryptsetup resize secret

Finally we can resize the filesystem. Here is an example for ext2/3/4:

e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs

resize2fs /dev/mapper/secret

You can now mount your container again:

mount /dev/mapper/secret /mnt/secret

swap presence should stop blocking operations

it is way too extreme to stop operations for the presence of swap; this behavior wasn't even discussed.

OTOH the swap vulnerability counts.

tomb runs as root so it could check for presence of a swap and execute swapoff/on -a

until this is implemented we cannot block the operation, but in case print out a warning.

easter egg in next release

For example an Ascii art image of boyska in a penis bouquet :D

automagic and temporary encrypted swap

The Ultimate solution of the swap issue!

Create a temporary encrypted swap file on tomb opening.

sudo/pinentry bug for password with spaces

They just seems not to work. Part of the problem is the awk expression

| awk '/^D/ { print $2 }'

create tomb steganographyng the key directly

want to create the tomb steganographyng contextually the key

something like:

tomb create --steganography -k /path/to/file.jpeg tomba -s 10

Close tombs on hibernation / suspend

Hibernating while a tomb is open is bad: it means that your key is written to disk.
We should close every tomb before hibernating.
This can be done using /etc/pm/sleep.d/99-tomb script which does this.

Also, if closing fails (because of pid locking it) we should choose between slamming and preventing hibernation.
Slamming is easier, but could be unintuitive for the user to "hibernate" and not finding his applications open on reboot.
Preventing hibernation seems to be possible, according to this post: http://askubuntu.com/questions/28328/how-can-i-disable-hibernate-completely-in-kubuntu

name key creating a tomb

will be confortable to choose the name and the location of the key creating the tomb

something like:

tomb create tomba -k /media/usb/name.tomb.key -s30

undertaker: polling

For gui interaction, polling is very useful. It is somehow implemented in tomb-open, for usb.
I propose implementation in undertaker, for ANY scheme. Just repeat calling the script until it finds a suitable key

This should be an option, --poll

option to choose tomb filesystem

Sometimes fat32 can be better than ext3 (especially for moving the tomb on another computer). Sometimes it's the opposite (fat32 has a lot of limitations).

We should add an option --filesystem=FSNAME to the create subcommand, to let the user choose it.

EDIT: still requested XFS and FAT32

warning if user has swap activated

Swap can be dangerous, because crypted files can be swapped out unencrypted.
We should warn the user, suggesting to

1. swapoff, or
2. setup encrypted swap

eliminate get_arg_tomb

# TODO: eliminate this function
get_arg_tomb $CMD2

present only in mount_tomb()

doesn't armonizes well with new optarg parsing

obsolete function to be removed

gpg password: problems with dash

Try it using passowrd -fasd. print will understand it as -f (that is, format) =asd and will print asd.
You can now open your tomb using asd as password. This wasn't the expected behaviour, and weaken your password. It's possible that even worse things happen.

mount point remove in any case

the mount points are removed also if not temporary created
deps in autoconf

change key password

changing the password is sometimes needed, because the previous one could have been revealed some way.
This will also allow to have different key copies with different passwords.

option "-s" doesn't check if argument is integer

that is, tomb -s asd create tombname will go on without complaining, but the tomb will be empty (because dd can't write "asd" blocks)

This also reveals that errors are not handled correctly

"slam" should try to kill more softly

kill -9 can be bad sometimes. It would be better to do a kill -USR1 first, then wait one second to see if some process survived, and only if necessary kill -9

key overwrite on usb

Suppose you create a tomb named 'foo', and put the key on a USB key.
Then you create another tomb named 'foo' (again) and put it on the same USB key.
Result: you have trashed the first key!

command line: steganografy support in 'open' subcommand

the use of steganography must be easier when opening the tomb.
something like:

tomb open tomba.tomb -k /path/to/file.jpeg --use-steganography

GUI

That's a really big one: writing a simple to use, almost-complete, secure GUI.
almost-complete means support for creating and opening. No esotheric options.
secure means that passwords are handled securely (pinentry)

Related: #59,#58

tomb almost full

Tomb should complain when it mounts a tomb which is almost full

Exit codes

When tomb exit with an aborted operation the exit code is still zero

this prevents GUI invoking it from exec( ) to understand the result

this need to be fixed and eventually a list of exit codes with different states can be made
the exit code number-to-string converted could even be a minor command, like "tomb strerror"

fix home search in exec_safe_bind_hooks function

if the line 6:

local HOME=$(grep $ME /etc/passwd | sed "s/^${ME}:.:.:.:.:([/a-z]):.$/\1/" 2>/dev/null)

give a two line output the result is not as expected

--no-color : better for GUIs and old terminal

Colors are nice, but not every terminal handles them correctly.
For example, the VIM terminal buffer does not :D, nor will it be easy to parse output from tomblib with ansi escapes inside.

decode_key() key overwrite

when decoding tomb key from image file, decode_key() overwrite an existing file:

steghide extract -sf ${imagefile} -p ${tombpass} -xf -
| awk '
BEGIN {
print "-----BEGIN PGP MESSAGE-----"
}
{ print $0 }
END {
print "-----END PGP MESSAGE-----"
}' > ${keyfile}

no check is made to ensure ${keyfile} already exist.

Packaging problems

There are mime packaging problems, but the patch is ready. This is just to remember ourselves to include it in tomb1.1

options order and bug

the correct tomb invocation is: tomb [command] [options] [file] [place]

Also, the -k option do not accept argument, then the only way to use tomb is that the tomb file and key must be on the same directory and do not use the -k flag.

tomb r/w lock

Use a lock file indicating the tomb is already mounted read-write
Default behaviour can be to mount read-only

This will let collective non-concurrent use of tombs on remote services (sshfs, clouds...)
still making sure only one user at a time is editing the Tomb.

nifty feature: inotify when lock is released and trigger mount -o remount,rw ....

undertaker: output path(s)

usually undertaker will output the key contents.
For GUI interaction, it would be good to just output its location, so that the user can confirm if he likes it or if he wants to choose another one.

This should be an option like '--print-path`

Permission issue when mounting on a computer with different UIDs

This is because of permission on ext3. Re-mapping dinamically everything seems to be difficult AND unpractical; there is no mounting option to force everything to be owned by user X.

Simplest solution could be just using a user-less filestystem, like... FAT32

tomb's mountpoint persistence

is not nice that the tomb's mountpoint persist on /media/...

Hooks not ignored when flag -n is set

When setting the -n flag, which tells tomb to do not execute pre-hooks and post-hooks, the script ignores that and always execute hooks.

Improve handling of LUKS key slots

This is a potential backdoor especially if Tomb doesn't checks the status of other LUKS specific key slots in a volume: a key can be added in the 2nd or 3rd slot without the user noticing, making the volume accessible with another key.

We need to check that all Luks slots are empty and allow the presence of only one key.

Or in case more keys are present then we need to make the user aware. However I'd be in favour of simplifying and removing the multiple slot functionality of Luks all in once, since it has some serious security drawbacks...

Debian: missing dependency on pkg-config

To be merged on the debian branch, cf. @e95cff2

delete tomb command from history

it would be nice to delete the tomb command from shell history

key from ssh remote server

maybe a new feature or a simple tomb source script to pick up the key when you open a tomb from a remote server via ssh connection.

code check and restyle

Check for unused vars and functions, fix some style bugs, clear indentation.

strange errors when combining sudo and output redirecting

If you run tomb create -s 10 /tmp/foo > /dev/null, everything is fine.
Even if you run tomb create -s 10 /tmp/foo 2> /dev/null.
BUT if you run tomb create -s 10 /tmp/foo &> /dev/null, sudo will have errors when called by pinentry.

You can reproduce this bug even in an easier way:
sudo -S -v &> /dev/null
Actually, it's not the /dev/null part that matters; you can redirect it even to $HOME/errfile. The redirection itself is the problem.
It probably has something to do with the fact that sudo closes every file descriptor.

Even if it seems that this is not a grave bug, for me it is: I am coding the GUI, and I'd like to parse tomb stdout/stderr to read errors, so I "redirect" the output to some buffers.

We could workaround this using always stdout (or stderr, no difference) when --machine-parseable (see #58); this way the GUI is no more affected by this.
What about real solutions ?

Related: #60

setting permissions on newly created tomb file failed

when creating a tomb, this commands failed (on create_tomb() ):
chmod 0600 ${tombfile}
chown $(id -u $ME):$(id -g $ME) ${tombfile}

this should be:

chmod 0600 ${tombdir}/${tombfile}
chown $(id -u $ME):$(id -g $ME) ${tombdir}/${tombfile}

Ensure minimum size of tomb matches FS requirements

Tomb allows for creation of too small tomb that the underlying file system cannot use.

e.g. tomb create -s1 is valid, but won't work. (Ext2 needs at least 4M)

machine parsable output

This will make it easy the integration with GUIs (see #60)
The support is almost there, because functions like notice, act or error are quite good at this.

A good enhancement could be progress
It should behave like this:
[%] CREATION Creating the key
That is: an identifier, a keyword and a message. This is good for the progressbar while creating the key, which could take a long time. Don't know if it is for anything else

This is of course a minor feature.