Automated LUKS Unlocking

[Nathaniel McCallum]

On Wed, 2016-03-16 at 17:51 -0400, Nathaniel McCallum wrote:
> On Wed, 2016-03-16 at 00:02 +0100, Bastien Nocera wrote:
> > 
> > On Tue, 2016-03-15 at 16:59 -0400, Nathaniel McCallum wrote:
> > > 
> > > 
> > > Sorry for the cross-post! However, I figured it was the best way
> > > to
> > > reach all the right people.
> > > 
> > > I'm the author of the Tang[1] project. In a nutshell, Tang
> > > provides
> > > a
> > > way to bind an encrypted disk to a network. We currently provide
> > > automated unlocking of the root volume (via initramfs/systemd).
> > > 
> > > However, one of our use cases is securing removable devices so
> > > that
> > > they can only be unlocked when the host computer is on a secure
> > > network. I have looked a bit at the code for GVFS and udisks, but
> > > it
> > > wasn't immediately obvious to me the best way to proceed in
> > > adding
> > > support for this. So I'm here looking for suggestions.
> > > 
> > > More or less, in order to automatically recover a disk's key we
> > > need
> > > read access to the LUKS header and network access to perform the
> > > Tang
> > > exchange. It would be my strong preference not to expose the
> > > metadata
> > > in the LUKS header to unpriviledge users.
> > > 
> > > I attempted to test this by provisioning a USB key using Tang.
> > > Upon
> > > insertion, GNOME (properly) prompts for the password. If I
> > > attempt
> > > to
> > > unlock the disk in the background during this operation, the
> > > password
> > > prompt is properly removed. However, the disk does not appear as
> > > a
> > > standard removable disk any more in Nautilus.
> > > 
> > > Thoughts? Suggestions?
> > Look at the output of "udisksctl dump". If your device shows up
> > there,
> > and depending on the value of the various properties it exposes
> > (especially the hints), it might be a bug in gvfs' udisks-based
> > volume
> > monitor.
> I was able to get things mostly working. But now I have the opposite
> problem. Namely, the gnome prompt doesn't disappear. I can cancel it
> and Nautilus seems to work fine. Should I file a bug against GVFS?

To reproduce the problem, create an encrypted usb key with the password
"foo". Then, execute the following in a terminal and immediately insert
the usb key (I am presuming here your usb key is on /dev/sdc):

sleep 10 ; busctl call org.freedesktop.UDisks2
/org/freedesktop/UDisks2/block_devices/sdc
org.freedesktop.UDisks2.Encrypted Unlock "sa{sv}" foo 0

When the key is inserted, the unlock dialogue pops up. After a few
seconds, the command executes and unlocks the disk. However, the
dialogue doesn't disappear. If you press cancel, and then view the disk
in nautilus, it works; until you try to eject it, then it gives an
error.

IMHO, GVFS/Shell/Nautilus should be able to cope with an out of band
process unlocking the inserted usb key.