Date: Wed, 20 Feb 2013 09:14:22 +0200 From: Alexander Yerenkow <yerenkow@gmail.com> To: Paul Schenkeveld <freebsd@psconsult.nl> Cc: hackers@freebsd.org Subject: Re: Chicken and egg, encrypted root FS on remote server Message-ID: <CAPJF9wns_sjpnNmk9bjnrUfqMKZ9jseRNB2oQdZsXFLkhgNVZw@mail.gmail.com> In-Reply-To: <20130220065810.GA25027@psconsult.nl> References: <20130220065810.GA25027@psconsult.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
2013/2/20 Paul Schenkeveld <freebsd@psconsult.nl> > 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? > I'd like to propose you to see my similar setup - it's used for VMs. Idea is to have base OS in little partition, and use it only in RO. All data, and configs goes in different partitions, which could be connected manually or automatically. What you need is to specify in loader.conf init_script="/etc/find-rwfs.sh" My example: https://github.com/yerenkow/freebsd-vm-image/blob/master/freebsd-firmware/find-rwfs.sh In this way, you can get RO booted OS, just waited for you to login and mount all required data. Also, you could contact Andriy Gapon, he managed to do other trick - boot from RO media such as CD, and run all OS as chroot, all transparently. Hope this helps! > 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-unsubscribe@freebsd.org" > -- Regards, Alexander Yerenkow
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPJF9wns_sjpnNmk9bjnrUfqMKZ9jseRNB2oQdZsXFLkhgNVZw>