# Bring up networking earlier during boot



## cfw (Nov 27, 2014)

I've got a default encrypted ZFS on root installation. I would like to run geliUnlocker in order to unlock the root partition automatically, problem is that the networking starts after the root partition is mounted.

Is it possible to bring up networking earlier?


----------



## asteriskRoss (Nov 27, 2014)

No. But you could start your encryption later.  Rather than encrypting the root partition, you could instead leave that unencrypted and then encrypt the partition(s) where your data is located (such as the partition for hosting /home).  You would need to configure this manually but if you're already familiar with zfs(8) and geli(8) then it's not too arduous.  Whether this approach is suitable will depend on what risks you are trying to mitigate.


----------



## Dies_Irae (Nov 27, 2014)

No, it's not possible.
GeliUnlocker needs ssh, which needs a configured network interfaces.
But network interfaces are configured in /etc/rc.conf which is in the root folder.
But the root folder is encrypted, and you need GeliUnlocker to mount it.
But GeliUnlocker needs ssh...


----------



## cfw (Nov 30, 2014)

asteriskRoss said:


> Rather than encrypting the root partition, you could instead leave that unencrypted and then encrypt the partition(s) where your data is located (such as the partition for hosting /home).


Leaving / unencrypted will make rescue operations much easier, that makes the compromise attractive. What data would leak when encrypting a jail partition instead of /home etc.?



Dies_Irae said:


> No, it's not possible.


There is an operating system where it's possible to load a small RAMdisk that enables networking and a small SSH server before booting the real system. Was wondering if something like that was possible with FreeBSD. Maybe boot from a small unencrypted root partition, unlock the main encrypted root partition and `chroot`?

Thanks


----------



## abishai (Dec 1, 2014)

Is ZFS can be encrypted at all? AFAIK, ZFS encryption was developed after OpenSolars deprecation and we have no sources of its implementation. On the ZFS-on-root system we can only use ZFS -> ZFS block device -> GELI -> ZFS-on-GELI, but I doubt the speed will satisfy anyone.


----------



## asteriskRoss (Dec 1, 2014)

This post ended up being longer than I expected  Let me respond to your post first and then make an alternative suggestion that may do what you need.

*Responses:*


cfw said:


> What data would leak when encrypting a jail partition instead of /home etc.?


I'm not quite sure what you mean. What are you trying to protect? Hard disk encryption protects your data at rest, that is, when your computer is powered off.  The most obvious use is on laptops, which might be lost or stolen.  For servers, it's useful if you're worried about the hard disks being stolen or thrown away at end-of-life without being securely destroyed.  It can also be used to verify the integrity of the data, such that you can detect if someone has tried to maliciously modify the encrypted files.  The configuration you have at the moment can't guarantee integrity since an attacker could modify the files on the unencrypted /boot partition, which could then report false results about file integrity.

Once your encrypted disks are mounted, they can be read like any other device and therefore don't offer any protection against network attacks (or unauthorised access to the machine locally) whilst the computer is running.



cfw said:


> Maybe boot from a small unencrypted root partition, unlock the main encrypted root partition and `chroot`?


An interesting idea. I believe this would work though I'm not sure what benefit it would give you.  The machine would still be running an unencrypted /boot and root partition; you would just be using a different userland after the chroot(8) call.



cfw said:


> There is an operating system where it's possible to load a small RAMdisk that enables networking and a small SSH server before booting the real system.


The concept is sound, though you would need a way of communicating the decryption key to GELI when booting FreeBSD.  It might be possible to pass it as a variable to the kernel, though I don't know how you could get GELI to pick up that variable.

*Suggestion for an alternative approach:*
If I understand correctly, you want the hard disks of your machines to be fully encrypted at rest.  The encryption keys should be held centrally and handed out on demand when the machines on the network boot.

Have you considered PXE boot?  My idea here is that your machines have a fully encrypted root partition on their local hard disks.  The /boot partition, including the kernel and GELI keys, resides on a read-only network share.  Your machines boot from that network share, unlock the local hard drive and then continue the boot process from there.  The vulnerability here would be if an attacker had access to your network, since the GELI keys would be freely available for anyone on the network.  However, if a machine were to be stolen, all the data on the hard disk would be safely encrypted and the key would remain on your network share.


----------



## asteriskRoss (Dec 1, 2014)

abishai said:


> On the ZFS-on-root system we can only use ZFS -> ZFS block device -> GELI -> ZFS-on-GELI, but I doubt the speed will satisfy anyone.


Yes, we're talking GELI encryption here.  For servers that need high performance, I agree GELI may add an unacceptable overhead.  Certainly it's not suitable if you're using devices for L2ARC.  However, I use ZFS on GELI on my laptops (both with and without processors that support aesni(4)) and I don't notice a difference for desktop use over an unencrypted disk; network and hard drive access speeds are my limiting factors.  I worry about my laptops being lost or stolen so encryption matters there.  My servers sit in a building protected with physical security and their hard disks are securely destroyed at end-of-life so encryption at rest doesn't offer such a worthwhile benefit.


----------



## Dies_Irae (Dec 1, 2014)

cfw said:


> Maybe boot from a small unencrypted root partition, unlock the main encrypted root partition and `chroot`?


No matters how many tricks you use to mount your encrypted filesystem, the system needs to boot from an unencrypted filesystem. You can't open a safebox if you keep the key inside it.

If you want automatic decryption you must save your keys somewhere in an unencrypted form, but this way they are exposed to the world. Suppose whe are talking about a laptop: if someone steals you laptop he can easily get you encryption keys, because they are saved in an unencrypted form. Even worse, if you use SSH keys the thief can use them to retrieve the encryption keys and gains access to a remote machine using your credentials. Hey, Christmas came early this year! 

I really prefer to keep the passphrase in my brain and type it every time the machine boots. From my point of view (and I'm not an expert at all, just my opinion), automatic decryption is like leaving the safebox keys inserted in the keyhole just to not have to remember where did you leave them last time.


----------



## cfw (Dec 1, 2014)

asteriskRoss said:


> I'm not quite sure what you mean. What are you trying to protect? Hard disk encryption protects your data at rest, that is, when your computer is powered off. For servers, it's useful if you're worried about the hard disks being stolen or thrown away at end-of-life without being securely destroyed.


This is precisely what I want to use the encryption for: to protect data at rest. What I meant was asking about the tradeoff between encrypting /home, /var and so on vs. encrypting just the ZFS filesystem on which a jail is installed. It seems to me that there is less data left unencrypted when using an encrypted jail within an unencrypted host. I'm not entirely sure whether my assumption is correct here because I am still somewhat unfamiliar with FreeBSD's jails.



asteriskRoss said:


> Have you considered PXE boot?


This is a great idea, I'll investigate whether I can set this up. Unfortunately the server is in a data center where I'm unlikely to be able to change much of the network.



Dies_Irae said:


> Even worse, if you use SSH keys the thief can use them to retrieve the encryption keys and gains access to a remote machine using your credentials.


You are entirely right that an attacker can retrieve the SSH key from the unencrypted partition, however that user account does not need to be able to have significant access to the system hosting the key. Further, the key can be revoked at any time or only be granted access when a reboot is planned and the filesystem it resides on can also be encrypted.

Previously I was manually connecting to a system that had a minimal SSH server waiting for me to unlock the disks. That method is tedious because it requires connecting at the right time during boot and swapping host keys.

Clearly the unencrypted portions can be tampered with and malicious USB devices can be connected, even the RAM can be read whilst the system is running to extract the key if immense effort is justified. Many of these attacks require a suspicious reboot and I'm not attempting to protect against scenarios of a targeted physical attack.

AES-NI can easily saturate 1 Gbit/s so there is absolutely no reason not to use it for my purposes.

I am absolutely flabbergasted at the lackadaisical way companies treat other people's information. The amount of negligence in regards to security is simply astounding and I'm not going to treat data I'm responsible for in such a manner. If I wanted to cut corners I would be using some cloud.

Thank you all for your insights, this forum is a breath of fresh air compared to some other open source operating systems.


----------



## asteriskRoss (Dec 1, 2014)

Thanks for sharing more about what you're looking to achieve, cfw, and I endorse your responsible but pragmatic approach to risk management   FreeBSD jails are great, not least from a security perspective to separate off different services, such that if one service is compromised, an attacker doesn't immediately have access to your entire system.  They are well worth the learning time investment.

For you, running your services in jails whose filesystems are encrypted would have some benefit in terms of any files created in /tmp or /var also being encrypted, rather than residing an unencrypted root filesystem.  A sensible architecture for what you want could be to boot the system from an unencrypted partition, which would allow you to use the geliUnlocker (or your own) script to attach and mount an encrypted partition where your jails reside.

ZFS is also great, provided you have the RAM for it.  If you wanted to use ZFS, you would need to set up a separate ZFS pool on top of the GELI provider for that second partition.  GELI providers can be attached on boot and ZFS datasets automatically mounted during boot (have a look at rc.conf(5) for details).  I have this set up and working fine on one of my systems.  You could also achieve the same with UFS if you prefer.

It would also be possible to use images for your jails, which could live as encrypted files on an unencrypted partition.  The excellent sysutils/ezjail port has support for such a configuration.  However, I would recommend the first approach (encrypting a whole partition for the jails) as it's more straightforward.

If you haven't already, you should also look at encrypting your swap partition, which could have any data from the system (host or jail) swapped out to it under heavy load.  I have my swap partition outside of ZFS, since I figure the process most likely to require swap is the memory-hungry ZFS itself.


----------

