Re: Automated LUKS Unlocking



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?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]