Fwd: Chicken and egg, encrypted root FS on remote server

[Jason Hellenthal]

Meant to also reply all...

Reply elsewhere...

-- 
 Jason Hellenthal
 JJH48-ARIN
 - (2^(N-1))


Begin forwarded message:

> From: Jason Hellenthal <jhellenthal at DataIX.net>
> Date: February 20, 2013 2:42:57 EST
> To: Paul Schenkeveld <freebsd at psconsult.nl>
> Subject: Re: Chicken and egg, encrypted root FS on remote server
> 

> Just a thought with no working example but…
> 
> bootp / tftp - from a remote secured management frame to TX a key filesytem to unlock your rootfs.
> 
> Could be something as simple as a remote wireless adhoc server with a 64GB thumbdrive to hold your data or just enough to tell the system where to get it.
> 
> Considering a key can be any length string of a sort just to say but... Serve the rootfs key directly from a TXT out of a secured DNS zone only visible to so said machines. 
> 
> Just a thought.
> 
> -- 
> Jason Hellenthal
> JJH48-ARIN
> - (2^(N-1))
> 
> 
> On Feb 20, 2013, at 1:58, Paul Schenkeveld <freebsd at psconsult.nl> wrote:
> 
>> Hi,
>> 
>> I've been trying to find a solution for this chicken and egg problem,
>> how to have an encrypted root filesystem on a remote server.
>> 
>> Geli can ask for a root password at the console to unlock the root fs
>> but that of course won't work for a remote server.
>> 
>> Ideally I'd like the server to start, do minimal network config, run
>> a minimal ssh client (dropbear?) and wait for someone to log in,
>> provide the passphrase to unlock the root filesystem and then mount
>> the root filesystem and do a normal startup.
>> 
>> I read about a pivotroot call in other OS-es, that would allow for a
>> very small unencrypted root filesystem to be mounted temporarily until
>> the passphrase has been entered and then swap that for a real, encrypted
>> root filesystem.  But AFAIK we don't have pivotroot.
>> 
>> The problem could also be solved if the real root fs could be union
>> mounted over the small unencrypted one but unionfs won't mount over /.
>> 
>> I found out that a ZFS pool where a specific dataset has the
>> mountpoint=/ option set can be used to 'buri' the unencrypted root under
>> the real root but that would render the unencrypted one unchangable
>> after the real one is mounted (prohibiting sysadmin to change the ssh
>> credentials or network config there).  It would also make maintenance
>> a bit more difficult because an import of the zpool would automatically
>> remount /, even when running from a cd-rom or USB stick.  And of course
>> this approach would not work in non-zfs environments (like very small
>> systems).
>> 
>> Looking at sys/kern/init_main.c and sys/kern/vfs_mount.c I could
>> imagine having a kind of "pre root environment", an unencrypted root
>> that gets mounted first (along with a devfs) and a /sbin/init that
>> sets up minimal networking and runs sshd.  Aftre that one dies the
>> unencrypted root and devfs would be unmounted, the real root mounted
>> and the real /sbin/init started.  But this may be a considered a dirty
>> approach.
>> 
>> Did I miss the obvious and easy solution?  Any ideas?
>> 
>> With kind regards,
>> 
>> Paul Schenkeveld
>> _______________________________________________
>> freebsd-hackers at freebsd.org mailing list
>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"