POC: encrypted rootfs

[moul]

• [x] Add Dropbear support (#65)
• [ ] Add encryption toolsuite binaries
• [ ] Add scripts and entrypoints using servers tags

We can use the work of @aimxhaisse from https://github.com/sbrk-org/pelmini/blob/master/scripts/custom-initrd/init-custom

[moul]

Dropbear support is merged

[Vlad1mir-D]

+1 for this feature

[neuhaus]

Any ideas how to prevent backdooring this image?

[moul]

From which image are you talking about ?

[neuhaus]

Well an image that is eventually created, allows you to log in via dropbear and then unlock your encrypted root partition.

[moul]

Ok, so you are talking about the initrd not about the scaleway images you can find on https://www.scaleway.com/imagehub/

Because, as soon as you use full encryption, you will need to use your own images, so I think you won't need me to avoid backdooring your own image :)

About the Initrd, for now, you can't upload your own (this may change in the future), but you can download it and as soon as you have a ssh access you can also scp the content of the initrd from the initrd to outside so you can compare shasum from the built initrd with the one you find in the running one

Also we will move to public travis builds so you will have a full log of initrd compilation + shasums

As soon as WE are running the software, you will need to trust us from a starting point, but as I just said, you can already download the existing initrd, rebuild it completely, send the live one and do comparisons

We are already happy to give customer real hardware instead of virtualization, and not being able to see what you are doing on your server :) if you have any ideas to improve the security of our service, feel free to contribute !

[neuhaus]

Yes, sorry I meant initrd image, not the imagehub stuff. Something that's part of what scaleway calls bootscript.

OK, the thing is as long as I don't have a private initrd, I can't put my SSH public keys in there which is the first problem (and no, I don't consider it safe to download them from the scaleway server during bootup).

The second problem is that the initrd is stored on the scaleway network SSD which means that the ISP can access the image whenever it wants without me noticing (to examine it and perhaps be forced to insert a backdoor). I don't really see a solution for that which is why I shut down my scaleway node and went back to my other dedicated server that has a local SATA disk. With a local SATA disk a 3rd party can't access the data without shutting down my server and making a copy which would result in unexplained downtime so I'd have at least a chance of noticing it. And inserting a backdoor would require another downtime and of course would be detectable (if only after-the-fact).

If you have a clever solution for these problems, I'd be very interested. I realize that this is not a problem that many people are having/seeing/considering a problem ;-)

[neuhaus]

One solution obviously would be Scaleway offering a new kind of server with a local SATA disk instead of the current offering with NBD disks.

[moul]

@neuhaus definitely, so stay tuned for next generation of our hardware

[moul]

In the mean time, we appreciate any help to get a nice solution for the C1 servers, if anyone as suggestion, feel free to share or contribute

---

I will also need votes etc about which solution do you prefer for rootfs encrypting ? luks cryptoloop / dm-crypt / encfs / new in-kernel ext4 encryption... which ones are your favorites ?

[tzelch]

I think it will be hard to make everybody happy but dm-crypt / luks should be the most commonly used Option. I'm looking forward to that feature very much!

[IceBear2k]

I'm also interested in this using LUKS/dm-crypt

[IceBear2k]

I've played around with this a bit and the way I currently see it, a solution for C1 would be this:

• Create a docker server with an additional storage device /dev/ndb1 which will be our encrypted target
• Install cryptsetup and git
• luksFormat /dev/nbd1
• luksOpen /dev/ndb1 to alias
• Clone Scaleway's Ubuntu image off git
• Adjust docker-rules.mk to point to /dev/mapper/alias instead of /dev/nbd0
• make install to install an Ubuntu base system to /dev/mapper/alias
• chroot to /mnt/dev/mapper/alias to install any additional required packages (cryptsetup, ? not quite sure what else is needed)

Now we could create an image from /dev/nbd1, but for testing purposes I just removed all volumes and reattached my encrypted system as /dev/ndb0

• Set server tag "INITRD_DROPBEAR=1" and reboot

Thanks to the already available dropbear support that automatically copies public keys from Scaleway, that's a breeze. In dropbear we'd need the cryptsetup suite now. Since we don't have that, I manually created and transferred a .tar.gz including cryptsetup tools which would normally be provided automatically when installing cryptsetup and executing "update-initramfs".

Where I'm currently stuck is that initrd doesn't seem to have dm_crypt loaded, so I can't use cryptsetup to open my device:

# /sbin/cryptsetup luksOpen /dev/nbd0 test
Cannot initialize device-mapper. Is dm_mod kernel module loaded?

I believe this would be possible with an initrd including cryptsetup tools and dm_crypt.

[moul]

@IceBear2k nice work, I will add missing assets

I have a much simpler idea for creating the image:

• use dropbear shell as you did to setup (first-time) and unlock (next times) a cryptsetup volume
• just use the already existing "live" mode which installs the content of a tarball to /newroot

So this is basically a standard live boot, as we are doing to create official images, except, the volume is encrypted first :)

[rvalle]

this is my first day as customer, and I came to this thread also.

Yes we are moving out of the public cloud not because we seek physical performance, but because we want physical security to better implement privacy.

I don't consider snapshots a sexy feature anymore, or the fact that you can dynamically attach disks to servers. On the contrary, that is one of the reasons why we are moving out of the Public Cloud.

Yes I also + 1 having full disk encryption, and exclusive SSD drives (a plain old physical SSD drive exclusively attached to my C1). We no longer care if it breaks because we have the capability to rebuild our servers at any time by using DevOps automation.

LUKS/dm-crypt is also good for us. We normally use LVM on top of it. We encrypt all volumes including swap.

[moul]

@rvalle thanks for your feedback, we should have the full disk encryption support in the initrd soon,

About the dedicated physical disk, we are working on something similar for the next hardware generations

[rvalle]

that sounds good. My first day of scaleway has been a mixed experience. lot of things that I like but some others that look like a step back from real hardware towards public clouds.

I am very happy to hear you are working on both.

meanwhile I have successfully encrypted and LVMed a second volume. Which should be workable until full HD encryption is implemented. 50GB for root seems like a waste, although a very cheap waste in case of scaleway.

I tried to partition the first volume so that I could dedicate only 10GB for root and the rest for encrypted LVM but I could not also. I would need the ability to specify boot parameters to the initrd and specify the root partition. I did not find anyway of doing it. (this should be easier to implement/workarount).

I think that limits my potential workarounds to the following:

• waste 40GB in the root partition and encrypt a second volume, where I place all the sensitive data.
• make a filesystem on top of a 40GB file, and take some extra overhead.

[juju2013]

Hi guys, As an alternate solution, you can try mine's, it's a simple script to create and boot full disk encryption ... comments welcome as usual.

[EtienneBruines]

@rvalle I'm no expert in this field, but doesn't this allow you to specify some boot parameters / root partition?

[dominic-p]

Hi guys, as a new Scaleway user I'm interested in this feature. It looks like this issue hasn't been touched in a little while. Is this still on the horizon for Scaleway?

[bprfh]

For me, this would be the deciding factor to move ressources to scaleway.

[GeeWee]

I know it's generally bad form to +1 as a comment, but I think it makes sense to spotlight this issue a bit since it's been.. well.. five years.