Date: Wed, 20 Feb 2013 02:44:41 -0500 From: Jason Hellenthal <jhellenthal@DataIX.net> To: "hackers@freebsd.org" <hackers@freebsd.org> Cc: Paul Schenkeveld <freebsd@psconsult.nl> Subject: Fwd: Chicken and egg, encrypted root FS on remote server Message-ID: <204C42A2-6381-4601-BEE7-D2AB56822468@DataIX.net> References: <C69A03DB-D861-4400-96B4-2DF5925CB4FC@DataIX.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Meant to also reply all... Reply elsewhere... --=20 Jason Hellenthal JJH48-ARIN - (2^(N-1)) Begin forwarded message: > From: Jason Hellenthal <jhellenthal@DataIX.net> > Date: February 20, 2013 2:42:57 EST > To: Paul Schenkeveld <freebsd@psconsult.nl> > Subject: Re: Chicken and egg, encrypted root FS on remote server >=20 > Just a thought with no working example but=E2=80=A6 >=20 > bootp / tftp - from a remote secured management frame to TX a key filesyte= m to unlock your rootfs. >=20 > 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. >=20 > Considering a key can be any length string of a sort just to say but... Se= rve the rootfs key directly from a TXT out of a secured DNS zone only visibl= e to so said machines.=20 >=20 > Just a thought. >=20 > --=20 > Jason Hellenthal > JJH48-ARIN > - (2^(N-1)) >=20 >=20 > On Feb 20, 2013, at 1:58, Paul Schenkeveld <freebsd@psconsult.nl> wrote: >=20 >> Hi, >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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 /. >>=20 >> I found out that a ZFS pool where a specific dataset has the >> mountpoint=3D/ option set can be used to 'buri' the unencrypted root unde= r >> 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). >>=20 >> 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. >>=20 >> Did I miss the obvious and easy solution? Any ideas? >>=20 >> With kind regards, >>=20 >> Paul Schenkeveld >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= "
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?204C42A2-6381-4601-BEE7-D2AB56822468>