Meant to also reply all... Reply elsewhere...
-- Jason Hellenthal JJH48-ARIN - (2^(N-1)) Begin forwarded message: > From: Jason Hellenthal <jhellent...@dataix.net> > Date: February 20, 2013 2:42:57 EST > To: Paul Schenkeveld <free...@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 <free...@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@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
