When https://lkml.org/ went down recently, I initially thought this had to do with the fact that the machine that was hosting it at the time was configured to use full disk encryption (FDE). No mechanism has been configured to provide it with the crypto key automatically, which means that rebooting such a machine requires a manual step.
This led to a question on reddit “why a machine which hosts a public visible mailinglist need[s] an encrypted drive?” There are several reasons why I’m using LUKS on this machine.
Basically using FDE in my mind should be a default, and if it is not being used, there should be a good reason for it. This might be caused by the fact that I have been working at a IT security company for most of this decade, and am now working at StartMail, an email provider that focusses on privacy. In both these environments, due to the nature of the data being processed, there should never be plaintext data being stored on disks - it is just considered basic digital hygiene, and I try to apply it to all data I store.
However, even though I think it is a good idea, this is not a very satifsying reason as it comes down to “I use LUKS because I always use LUKS.”
Here are two stronger arguments for using LUKS in this specific case:
The machine on which https://lkml.org/ was hosted is also used to host other VMs and data. Examples of these include VMs with my pet projects, but also my private mail [1] and backups of my other machines and photographs.
So, one reason I use LUKS is that there is private data on that machine that should not fall into the wrong hands.
You might ask if that is an actual risk? It is - I’ve had several drives fail on me in the last years under warranty, and I’ve been able to just pull them out of the machine and send them back to the shop or manufacturer without having to do a round of wiping, because I know that the data is encrypted securely. I hope those disks will not be dusted off and flashed with another firmware to be sold as refurbished ones, but if that happens, I don’t want my data to be on them. [2]
I’ve also gotten rid of disks that haven’t failed yet: when upgrading, I think it is a waste to throw away perfectly fine hardware, even if it is outdated, so I tend to sell or give away old hardware on the Marktplaats, the Dutch craigslist. Again, not having to wipe those disks
I am a European citizen. This means that on May 25th of 2018, the General Data Protection Regulation (GDPR) will come into force. I am not a lawyer or GDPR expert, but I do know that hosting a public mailing list archive is affected by this. The best known part of the GDPR is “the right to be forgotten”, which states that it should become possible for individuals to have access to data about them to be removed. I am still thinking about how to implement this for lkml.org and will get back to that in a later article.
A right more relevant to this post is the “Privacy by Design” part. Even though I am not a GDPR expert, I do claim knowing a thing or two about privacy, and applying FDE is one measure that should be applied to make it harder to cause privacy breaches.
For me, all these points are valid reasons for applying FDE to “a machine which hosts a public visible mailinglist”. Now go on and read up on how to implement FDE for all of your systems.
| [1] | Yes, I am aware of the fact that I work at an email service provider and am hosting my private mail. It’s just that I’ve been hosting my personal email myself for the last twenty years or so and don’t mind spending a small bit of time on keeping that setup working. Besides, having experience with hosting mail helped me with getting my current job. |
| [2] | I know that lots of companies will have “Keep Your Drive” (KYD) agreements with their suppliers, so they can destroy failed drives and get fresh ones without having to expose their data. By employing FDE rigorously, you can just let Dell stare at your encrypted data and don’t have worry about KYD. |