Encrypted Filesystem - Feature Suggestion

[Joe Baker]

An encrypted filesystem would be a great feature along with an ssh daemon in the initramfs that allows for entry of the passphrase needed to decrypt the whole disk encryption. An additional routine that would run a hash of the contents of the /boot partition to ensure nothing has changed since the last system update. This is because if the server went into the hands of someone who could insert malicious code into the /boot partition.

I'd always hoped to host encrypted servers on various continents and administer them remotely.

 

[fabian]

An encrypted filesystem would be a great feature along with an ssh daemon in the initramfs that allows for entry of the passphrase needed to decrypt the whole disk encryption. An additional routine that would run a hash of the contents of the /boot partition to ensure nothing has changed since the last system update. This is because if the server went into the hands of someone who could insert malicious code into the /boot partition.

I'd always hoped to host encrypted servers on various continents and administer them remotely.

see https://forum.proxmox.com/threads/official-full-encryption-support.21951/#post-154333

 

[Rhinox]

It is a pitty open-zfs does not include native encryption, with all zfs-like goodies (per dataset/volume/file, etc), while zfs for solaris does. AFAIK, this feature has been requested on ZoL mailing-list many times...

 

[fabian]

It is a pitty open-zfs does not include native encryption, with all zfs-like goodies (per dataset/volume/file, etc), while zfs for solaris does. AFAIK, this feature has been requested on ZoL mailing-list many times...

there is a long-running effort to implement this for both open-zfs and zfs-on-linux (which are not identical):
https://github.com/openzfs/openzfs/pull/124
https://github.com/zfsonlinux/zfs/pull/5769

unfortunately, just wishing it were here already doesn't make it so

 

[LnxBil]

This is because if the server went into the hands of someone who could insert malicious code into the /boot partition.

They could also have changed the hash and replaced all the GPG keys to check if the signed hash is still correct. As long as /boot is writeable, it is attackable and replacing your initrd with a totally custom one to trick you is simple. As long as there is no hardware signature checking for that (like on ARM nowadays), this is always attackable.

It's really, really hard to secure your remote servers. I'd start by placing my server into a tier 3 or 4 datacenter with physical access control to your rack or rack part, use self-encrypting devices, hardened bios settings, case-open protection, etc. before trying to secure your software. We use externally-triggered decryption (automatically via Icinga) of our ZFS pool similar to the suggestion from @fabian, yet of course this is not 100% secure - nothing is :-D

I'd really like to hear what you will do.

 

[mir]

This is because if the server went into the hands of someone who could insert malicious code into the /boot partition

By security definition your server is to be considered compromised if others have had physical access to it.

 

[Joe Baker]

Yes, and I appreciate that. It is a consideration. Just trying to make it increasingly harder for those who might handle the equipment to modify contents of the drive. Obviously hardware hacks are possible. In any case I'm delighted to learn that Proxmox can be installed on top of Debian. So I could devise and implement such a system and this is splendid indeed.