Automated LUKS Unlocking

[Nathaniel McCallum]

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?