[zfs-discuss] ZFS on root: Additional question

Gregor Kopka zfs-discuss at kopka.net
Fri May 20 18:00:31 EDT 2016



Am 20.05.2016 um 11:29 schrieb Schlacta, Christ:
>
>
> On May 20, 2016 2:08 AM, "Gregor Kopka via zfs-discuss"
> <zfs-discuss at list.zfsonlinux.org
> <mailto:zfs-discuss at list.zfsonlinux.org>> wrote:
> > I have encrypted servers (with ZFS root) on which I need to restart
> and unlock without physical access, they boot into a minimal root
> (running SSH to get key material into them) so they need some stuff in
> /var to boot.
>
> Have you looked into doing this from initrd? That would save you the
> later mount shuffles. You can add everything sshd needs into a hook, 
> and fire it up under a different name before the system starts
> actually running stuff
>
I could, but it isn't worth the hazzle since I don't have to override
that much and, more important, it is already working as intended.


> > Solution I came up with: the unlocking script imports the encrypted
> pool without mounting the filesystems in it, overloads/replaces
> populated filesystems like /var/log, /var/run and others like ~/.ssh
> (from the root pool) with datasets from the then decrypted pool, with
> them in place restart anything anchored in the original filesystems
> (on the root pool, getting list of processes to restart by lsof prior
> to the filesystem mount juggling, this is mainly sshd), zfs mount -a
> and then init into a custom runlevel to start the services the box
> should provide.
>
> If you're just trying to prevent a thief from gaining access and are
> comfortable with the machine posting automatically when it's in the
> right location,  you can use something like curl with client https
> certs to retrieve the unlock key from a remote https server on site.  
> Mutual verification prior to post.server won't be able to boot off site.
>
Then I would need at least one additional server onsite (doctors
office), and in case you would carry them both away you could unlock the
medical data on them.
Sure, I could hide a RPi somewhere but in the end it would be not good
since the idea is that without key material (from a physical USB key
that isn't onsite, or a /really/ complex passphrase for remote unlock)
you get several TB of white noise, even when carrying away everything
mildly related to IT.

Gregor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.zfsonlinux.org/pipermail/zfs-discuss/attachments/20160521/343c9604/attachment.html>


More information about the zfs-discuss mailing list